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Abstract 


The  modeling  and  simulation  (M&S)  community  relies  on  terrain  databases  to  provide 
the  underpinnings  that  drive  analysis,  acquisition,  and  training.  Terrain  database  generation  is 
cost  and  time  prohibitive.  Furthermore,  the  problem  of  organizing  these  terrain  databases  is 
much  more  difficult  than  maintaining  a  catalog  of  paper  maps.  Reuse  of  terrain  databases  is 
hampered  by  the  difficulty  in  identifying  and  accessing  existing  terrain  databases  with  potential 
for  reuse.  Terrain  databases  not  only  vary  by  the  geographic  extents  which  they  encompass  but 
also  vary  by  terrain  database  format  as  required  by  different  simulation  programs  and  platforms, 
by  the  amount  of  detail  in  terms  of  features  and  attributes  contained,  and  by  the  resolution  and 
fidelity  among  other  factors.  Thus,  there  may  be  several  different  terrain  databases  for  the  same 
geographic  location  but  not  all  may  be  useful  for  particular  M&S  or  for  specific  studies  and 
analysis.  This  report  discusses  the  application  of  the  Systems  Engineering  and  Management 
Process  (SEMP),  taught  by  the  Department  of  Systems  Engineering  at  the  United  States  Military 
Academy,  in  developing  a  metadata  framework  for  organizing  these  terrain  databases  as  a  means 
to  facilitate  reuse  and  reduce  redundancy.  Specifically,  we  focus  on  choosing  among  potentially 
dozens  of  descriptive  metadata  fields,  considering  the  need  for  easy  search  capability  as  well  as 
initial  data  entry.  We  also  discuss  related  initiatives  within  the  community. 
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Chapter  1:  Introduction 


1.1  Background 

The  United  States  Army  uses  modeling  and  simulation  (M&S)  for  a  wide  array  of 
purposes,  ranging  from  materiel  acquisition  to  doctrinal  and  force  structure  analysis,  to  soldier 
training  to  wargaming  tactical  courses  of  action.  There  are  numerous  M&S  used  for  these 
applications.  Terrain  databases  provide  the  information  about  the  environmental  conditions  of  a 
particular  location  and  are  utilized  by  the  M&S  to  execute  the  simulation. 

Terrain  database  generation  is  cost  and  time  prohibitive.  Furthermore,  the  problem  of 
organizing  these  terrain  databases  is  much  more  difficult  than  maintaining  a  catalog  of  paper 
maps.  These  databases  are  similar  to  maps:  they  contain  the  information  about  the  relief, 
vegetation,  hydrology,  as  well  as  man-made  features,  of  a  location.  However,  they  are  dissimilar 
from  maps  in  that  each  one  may  have  only  portions  of  any  of  that  information,  at  varying  levels 
of  detail,  or  the  data  may  have  been  customized  by  a  previous  developer.  Further,  each  M&S 
requires  its  own  language  or  format.  The  result  is  that  there  can  be  several  dozen  unique  terrain 
databases  for  a  single  geographic  location. 

Reuse  of  terrain  databases  is  hampered  by  the  difficulty  in  identifying  and  accessing 
existing  terrain  databases  with  potential  for  reuse.  Unfortunately,  Army  analysts  who  need  a 
particular  area  or  set  of  terrain  features  must  rely  on  their  own  collection  of  databases,  other 
repositories  of  which  they  are  aware,  or  their  network  of  contacts  to  search  for  terrain  databases. 
Failing  that,  they  often  resort  to  constructing  their  own  terrain  database,  a  time-consuming 
process  that  exacerbates  the  overall  problem  by  increasing  the  number  of  databases  in  the 
community. 

The  Battle  Command,  Simulation  &  Experimentation  Directorate  (BCSE)  is  responsible 
for  the  management  of  M&S  within  the  Army  M&S  community.  As  such,  it  charged  the 
Operations  Research  Center  (ORCEN)  in  the  Department  of  Systems  Engineering  (DSE)  at  the 
United  States  Military  Academy  (USMA)  to  investigate  the  current  state  of  terrain  database 
management.  Specifically  we  have  studied  this  problem  with  the  goal  of  determining  which 
metadata  are  required  to  efficiently  organize  and  provide  access  to  these  terrain  databases.  The 
results  of  this  study  are  offered  for  incorporation  into  the  Army  Digital  Terrain  Library  (ADTL), 
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a  terrain  database  (TDB)  repository  for  use  by  analysts  across  the  Army.  In  this  report,  we  begin 
by  providing  our  recommendations.  Next  we  discuss  our  approach,  beginning  with  a  description 
of  the  problem  and  the  related  systems  and  initiatives  currently  in  use  or  under  development  in 
the  community.  Finally,  we  describe  our  results  and  findings  and  conclude  by  explaining  the 
rationale  for  our  recommendation  to  BCSE. 

1.2  Recommendation 

Based  on  the  research  described  below,  we  generated  a  series  of  recommendations.  First, 
there  should  be  two  sections  of  metadata  about  a  database:  one  that  is  required  for  entry  and 
another  that  is  optional.  The  required  entries  provide  enough  detail  to  give  an  analyst  a  basic  set 
of  database  characteristics.  They  also  limit  the  workload  of  the  individual  posting  information 
about  a  database  they  created.  The  optional  entries  provide  much  greater  detail  about  a  database 
but  would  increase  the  burden  of  the  initial  posting.  The  required  entries  are: 

•  Terrain  database  coordinate  system  used 

•  Location  represented 

•  Format  (simulation  model  compatibility) 

•  Whether  roads  are  represented 

•  Whether  vegetation  is  represented 

•  Level  of  detail  of  elevation  source  data 

•  Level  of  detail  of  topography  representation 

•  Application  of  the  database  (a  viewer  or  a  run-time  format) 

•  Point  of  contact  for  the  database 

The  optional  entries  are: 

•  Whether  structures  are  represented 

•  Whether  cultural  features  are  represented 

•  Whether  hydrology  is  represented 

•  Whether  soil  types  are  represented 

•  Whether  littoral  features  are  represented 

•  Level  of  detail  of  cultural  source  data 

•  The  lineage  of  the  database 

•  The  title  of  the  database 

•  The  publication  date  of  the  database 

Second,  we  recommended  that  this  repository  have  two  additional  functions:  an  email 
reflector  and  the  ability  for  analysts  to  post  information  about  a  database  after  they  have  used  it. 
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The  first  will  allow  users  to  contact  each  other  and  truly  build  a  community  of  users.  The  second 
will  create  a  more  robust  set  of  information  about  a  particular  database. 

Currently,  we  are  in  the  process  of  populating  this  framework  for  the  library  with  terrain 
databases  from  a  limited  number  of  organizations  around  the  Army.  Doing  so  will  allow  us  to 
collect  a  trial  set  of  databases,  which  is  itself  a  useful  product.  It  will  further  provide  feedback 
on  the  metadata  so  that  we  may  refine  it  as  needed.  Other  agencies  are  investigating  proposed 
physical  locations  for  the  Army  Digital  Terrain  Library.  Following  those  efforts,  the  ADTL 
should  continue  to  be  populated,  searched  and  accessed  by  individuals  and  organizations  from 
around  the  Army. 

1.3  General 

1.3.1.  Battle  Command,  Simulation  &  Experimentation  Directorate 

The  Battle  Command,  Simulation  &  Experimentation  Directorate,  formerly  known  as  the 
Army  Modeling  and  Simulation  Office  (AMSO),  now  has  AMSO  as  one  of  its  three  divisions. 
The  BCSE  is  the  Army  Proponent  for  Battle  Command,  Simulation,  Experimentation,  Testing 
and  Exercises.  In  part,  it  is  responsible  for  M&S  oversight  and  management  in  the  three  M&S 
domains:  research,  development,  and  acquisition;  advanced  concepts  requirements;  and  training 
exercises  and  military  operations.  BCSE  is  the  Army’s  focal  point  for  integration,  analysis, 
prioritization,  and  standardization  of  Battle  Command.  BCSE  also  deals  with  strategy,  oversight, 
investment,  and  cross-domain  integration  for  M&S  activities.  Thirdly,  it  “coordinates, 
synchronizes,  and  recommends  priorities  for  concept  experimentation,  testing  and  exercise 
requirements.”  BCSE  also  serves  as  the  Functional  Area  57  proponent  and  corresponding 
civilian  career  field  developer.  The  directorate  is  organized  into  four  subordinate  groups  to 
accomplish  these  functions,  each  one  with  their  own  responsibilities.  Colonel  George  Stone  is 
the  Director  of  BCSE  and  is  our  client.  The  organizational  diagram  is  shown  in  Figure  1  below. 
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Figure  1:  Battle  Command,  Simulation  and  Experimentation  Directorate 


1.3.2.  Systems  Engineering  and  Management  Process  (SEMP) 


The  Department  of  Systems  Engineering  at  the  United  States  Military  Academy  teaches 
its  cadets  the  Systems  Engineering  and  Management  Process  (SEMP)  as  a  problem-solving 
technique.  In  conducting  this  study,  we  used  portions  of  the  SEMP,  finishing  with  the 
presentation  of  our  recommendation  in  the  Decision  Making  phase.  The  SEMP  is  shown  in 
Figure  2  below. 


The  first  phase  of  the  SEMP,  Problem  Definition,  begins  with  the  initial  problem 
statement,  usually  taken  from  the  client.  Armed  with  that  statement,  the  analyst  begins  a 


Figure  2:  Systems  Engineering  and  Management  Process 
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thorough  study  of  the  needs  of  the  system.  This  is  largely  based  upon  background  research  and 
stakeholder  interviews  and  results  in  a  better  understanding  of  the  functions  of  the  system  as  well 
as  of  the  environment  in  which  it  operates.  That  process  leads  to  a  revised  problem  statement  -  a 
more  specific,  clearly-defined  statement  of  the  client’s  need.  It  is  also  the  foundation  for  the 
Value  System  Design,  which  quantifies  the  beliefs  of  the  stakeholders  as  to  which  functions  or 
capabilities  are  most  important. 

Given  the  revised  problem  statement  and  value  system  design,  the  analyst  enters  the 
second  phase,  Design  and  Analysis.  Since  this  is  an  iterative  process,  it  often  is  the  case  that  the 
analyst  returns  to  the  Problem  Definition  phase.  This  study  is  no  exception;  much  of  the  input 
required  in  modeling  and  analysis  was  provided  by  the  stakeholders  identified  earlier.  Within 
Design  and  Analysis,  the  analyst  develops  candidate  solutions,  then  uses  various  techniques  to 
model  them  to  determine  their  feasibility  and  effectiveness.  Each  of  the  feasible  alternatives  is 
then  considered  against  the  Value  System  Design  and  moves  into  the  third  phase  of  the  SEMP, 
Decision  Making.  This  report  will  detail  our  progress  up  to  the  decision  making  phase,  since  we 
have  concluded  this  study  with  our  recommendation  to  BCSE. 

Chapter  2:  Problem  Definition 
2.1  Needs  analysis 
2.1.1.  Initial  problem  statement 

In  the  summer  of  2004,  the  Army  Modeling  and  Simulation  Executive  Council  (AMSEC) 
“directed  the  Army  Model  and  Simulation  Office  (AMSO)  to  develop  an  inventory  of  Army 
Digital  Terrain  databases  that  can  be  made  available  to  potential  users”  (Inventory  Tasking 
Memo).  In  order  to  accomplish  this,  AMSO  requested  that  Army  analytical  agencies  compile 
and  send  descriptions  of  each  of  their  TDBs.  These  TDBs  would  become  part  of  Army  Digital 
Terrain  Library.  In  August  2004,  COL  George  Stone,  Director  of  the  Battle  Command, 
Simulation  and  Experimentation  Directorate  (BCSE)  (which  includes  AMSO),  asked  the 
Operations  Research  Center  of  Excellence  at  USMA  to  conduct  a  study  in  support  of  the  ADTL. 
Specifically,  our  initial  problem  statement  was  “compile  a  list  of  all  Army  modeling  and 
simulation  terrain  databases”  with  the  understanding  being  that  we  would  apply  the  SEMP  to  get 


5 


at  the  stakeholders  issues  through  needs  analysis  and  refine  the  problem  statement.  Our 
statement  of  work  did  not  include  the  exhaustive  compilation  of  terrain  databases. 

2. 1 .2.  Initial  background  research 

We  began  this  study  by  stepping  back  from  that  initial  problem  statement  and  attempting 
to  break  down  the  problem  into  its  components.  This  was  largely  accomplished  through 
discussions  with  experts  in  the  community,  specifically  those  who  deal  with  environmental 
aspects  of  modeling.  That  provided  a  greater  understanding  of  related  systems  and  initiatives 
already  underway,  or  existing,  at  other  agencies. 

2. 1.2.1  Initial  Stakeholder  discussions 

There  were  several  important  observations  from  our  initial  discussions  with  these 
stakeholders.  First,  it  was  accepted  that  a  repository  such  as  the  one  conceptualized  as  the  ADTL 
would  be  very  useful  for  analysts  in  the  field.  Currently,  an  analyst  either  must  possess  a  TDB 
that  meets  his  criteria,  contact  a  colleague  who  does  which  can  include  finding  it  in  an  existing 
repository,  or  build  the  database.  Therefore,  it  was  initially  observed  that  a  repository,  one  able 
to  be  searched  and  accessed,  would  be  very  useful.  We  confirmed  this  observation  with  our  first 
questionnaire. 

The  second  point  is  that  it  is  also  important  to  know  how  well  a  database  meets  the 
analyst’s  criteria  for  use.  Analysts  around  the  Army  conduct  a  wide  range  of  studies,  and 
knowing  the  specific  characteristics  of  the  underlying  TDB  is  critical  to  the  results.  Before 
beginning  a  study,  he  needs  to  know  not  just  if  a  particular  TDB  represents  a  specific  location. 

He  must  also  know  what  portions  of  and  to  what  level  of  detail  the  environment  is  represented. 
The  key  to  this  knowledge  is  the  metadata  used  to  describe  the  database  itself. 

A  third,  fairly  obvious  but  no  less  important  observation  is  that  such  a  repository  needed 
to  be  easy  to  use,  from  both  the  standpoint  of  the  person  reposing  a  database  as  well  as  the 
person  searching  for  a  database.  While  this  is  a  simple  point,  it  leads  in  opposing  directions.  A 
repository  that  is  easy  to  populate  would  allow  a  person  to  post  a  database  with  a  minimum  of 
background  information  about  it.  On  the  other  hand,  to  productively  search  the  repository,  a  user 
would  like  to  search  on  as  many  characteristics  as  possible  and  therefore  require  a  great  deal  of 
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background  information.  Those  competing  interests  have  grown  into  the  main  thrust  of  the 
project. 

Fourth,  these  early  discussions  broadened  our  view  of  the  community,  since  they 
highlighted  the  concurrent  development  of  several  similar  systems.  That  knowledge  led  us  to 
more  background  research  about  terrain  databases,  other  organizational  systems  in  place  or  under 
development.  Each  of  those  contributed  to  a  more  detailed  decomposition  of  our  system. 

2. 1.2. 2  Terrain  Databases 

Terrain  databases  (TDBs)  provide  the  underpinnings  for  computer  combat  models.  They 
include  required  information  about  a  particular  geographic  location  and  provide  the 
environmental  infrastructure  for  the  conduct  of  a  simulation  run  -  they  are  the  “map”  on  which 
the  entities  operate.  Unfortunately,  they  are  much  harder  to  classify  or  categorize  than  paper 
maps  for  a  variety  of  reasons. 

These  files  can  range  in  size  from  two  to  three  megabytes  for  a  very  general  depiction  of 
an  area  to  two  to  three  terabytes  or  larger  for  a  very  detailed  representation.  While  the  size  of  the 
area  represented  can  vary,  in  general  there  are  separate  files  for  separate  scenario  locations,  so  an 
analyst  may  have  one  TDB  for  Caspian  Sea  and  another  for  Fort  Benning,  Georgia. 

Furthermore,  the  differences  between  databases  can  be  quite  significant.  The  following  example 
contrasts  the  characteristics  of  terrain  databases  with  those  of  a  paper  map  to  highlight  the 
challenges. 

A  map  of  Fort  Benning  Georgia  can  be  classified  by  several  features:  the  type  of  map 
(political,  road,  physical),  the  level  of  detail  provided  (1 : 12,500  km  or  1:50,000  km),  or  the  date 
of  publication  for  example.  However,  within  each  map,  the  features  depicted  do  not  change 
considerably. 

On  the  other  hand,  a  terrain  database  of  Fort  Benning  can  be  categorized  by  many 
features  and  attributes  with  a  variety  of  enumerations.  Each  simulation  program  has  its  own 
language  or  format.  That  is,  the  combat  models,  OneSAF  Objective  System  (OOS),  Janus,  and 
Joint  Conflict  and  Tactical  Simulation  (JCATS)  do  not  use  the  same  TDB  formats.  Therefore, 
Fort  Benning  will  be  represented  in  three  separate  formats,  and  each  one  is  a  separate  TDB. 
Further,  there  may  be  different  source  data  used  to  build  the  a  terrain  database,  even  for  the  same 
geographic  area.  It  is  plausible  to  have  a  database  which  was  constructed  from  very  accurate  10- 
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meter  elevation  postings  (referred  to  as  DTED  1),  less  accurate  100-meter  postings  (DTED-2),  or 
even  aerial  imagery. 

Further  complicating  the  matter,  TDBs  may  represent  different  features  on  the  ground. 
One  TDB  for  Fort  Benning  could  represent  a  specific  urban  setting  very  precisely,  including 
roads  and  buildings  with  interiors,  while  representing  the  surrounding  vegetation  very  simply. 
Another  may  include  all  rivers  and  creeks,  but  default  their  width  to  a  particular  dimension  to 
control  mobility.  Additionally,  it  is  possible  for  trained  users/developers  to  start  with  a  TDB, 
then  modify  it  for  their  needs,  based  on  other  sources  to  increase  or  simplify  detail  in  certain 
areas. 

The  result  of  all  of  these  potential  variations  is  an  uncountable  number  of  terrain 
databases.  For  the  ADTL  to  be  a  useful  resource  for  those  in  the  community,  it  must  be 
organized  with  these  facts  in  mind.  The  key  task  in  its  organization,  and  the  motivation  for  this 
study,  is  a  structured  study  of  the  metadata  that  is  important  to  those  who  use  TDBs. 

2. 1.2. 3  System  decomposition 

It  is  critical  to  the  SEMP  to  take  a  wide  view  of  the  initial  problem  statement.  By  doing 
so,  we  gain  a  greater  appreciation  for  the  true  scope  of  the  problem  and  the  environment  in  which 
it  operates.  A  key  part  of  doing  this  is  decomposing  the  system  into  its  component  functions,  as 
well  as  identifying  related  or  parallel  systems,  as  well  as  supersystems  in  which  the  ADTL  would 
operate. 

2. 1.2. 3.1  Component  functions 

Given  the  initial  problem  statement,  we  originally  started  with  the  impression  that  we 
were  developing  the  entire  repository  of  TDBs  and  decomposed  its  functions.  The  repository 
could  conduct  several  functions.  There  must  be  a  method  of  accessing  the  databases  -  a  search 
capability.  There  must  also  be  a  method  of  entering  or  reposing  the  databases.  Finally,  the 
repository  must  contain  the  databases  themselves.  We  needed  to  consider  each  of  those  in  our 
analysis. 

The  terrain  databases  themselves  certainly  form  the  content  of  the  repository.  That  fact 
led  to  the  question  of  the  storage  of  those  TDBs.  Reposing  the  databases  at  a  single  location 
would  allow  relative  ease  of  management  of  the  library.  However,  the  size  of  these  files  imposes 
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a  significant  constraint  on  the  capacity  of  any  system.  Further,  many  TDBs  require  security 
measures  and  release  authority.  On  the  other  hand,  reposing  the  databases  on  a  distributed 
system  removes  the  capacity  constraint  for  a  single  location  and  allows  the  individual  manager 
the  ability  to  control  access  to  the  database.  But  doing  so  also  would  make  it  difficult  to  manage 
from  a  centralized  location.  This  is  exacerbated  by  the  fact  that  as  individual  agencies  update 
file  locations  or  network  connections,  each  such  pathway  would  also  have  to  be  updated.  In 
either  method,  it  would  be  necessary  to  download  a  database  file,  but  given  their  size,  doing  so  is 
tenuous. 

As  we  considered  all  of  these  questions,  we  returned  to  our  initial  problem  statement  and 
the  impetus  for  the  project.  We  soon  realized,  and  confirmed  in  an  In-Progress  Review  (IPR), 
that  our  goal  was  not  to  build  the  entire  repository.  Our  project  would  be  an  important  part  of  the 
repository,  defining  the  best  metadata  for  organizing  the  repository.  That  metadata  would  drive 
the  functions  of  searching  for  and  posting  a  database.  An  added  functionality  for  the  ADTL  that 
came  out  of  our  study  was  to  increase  the  cross-talk  of  users  in  the  community. 

2.1. 2.3.2  Supersystems 

A  supersystem  is  any  system  that  encompasses  or  provides  regulation  or  direction  to 
another  system.  One  such  system  to  the  ADTL  is  the  Army  Geospatial  Data  Integrated  Master 
Plan  (AGDIMP).  The  AGDIMP  provides  the  policy  and  guidance  for  management  of  geospatial 
data.  It  describes  the  Army’s  overarching  strategy  for  managing  geospatial  data  whether  for 
modeling  and  simulation  or  for  battle  command  and  communication  systems.  The  ADTL  will 
work  within  the  constructs  of  the  AGDIMP. 

Another  system  with  the  same  type  of  relationship  is  the  Joint  Geospatial  Enterprise 
System  (J-GES).  Currently  under  development,  the  J-GES  has  the  goal  of  being  a  distributed 
repository  for  global  geospatial  information  for  battle  command  and  communications  systems.  It 
will  be  interoperable  with  all  services  and  will  provide  a  constantly-updated  map  of  virtually  any 
location  in  the  world.  Its  focus  is  on  providing  information  to  tactical  and  operational  units, 
potentially  to  the  level  of  the  individual  soldier.  As  modeling  and  simulation  capabilities  are 
more  available  to  deployed  units,  the  ADTL  could  work  within  the  framework  of  the  J-GES. 

A  third  supersystem  to  the  ADTL  is  the  National  Geospatial-Intelligence  Agency  (NGA). 
NGA  is  the  country’s  source  of  geospatial  information,  whether  it  regards  political  boundaries, 
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urban  specifications  or  maritime  applications.  It  may  provide  the  source  data  for  building  a 
terrain  database.  The  ADTL  will  work  with  and  within  programs  and  systems  from  NGA. 

2.1. 2.3. 3  Parallel  systems 

Among  parallel  systems,  it  is  important  to  consider  that  each  of  these  uses  their  own 
metadata  standard.  Therefore,  not  only  is  the  system  itself  parallel  in  nature  to  the  ADTL,  its 
metadata  is  parallel  to  the  metadata  we  recommended. 

The  first  of  the  parallel  systems  is  the  Synthetic  Environment  Data  Representation  and 
Interchange  Specification  (SEDRIS)  and  the  underlying  Environmental  Data  Coding  Standard 
(EDCS).  While  SEDRIS  is  not  a  repository,  it  does  allow  the  interchange  of  geospatial  data, 
thereby  enabling  reuse  for  different  software  formats.  It  is  a  mechanism  that  allows  for  the 
interpretation  of  geospatial  data  from  one  format  to  another.  Using  SEDRIS  and  the  EDCS,  a 
user  can  describe  geospatial  data.  The  EDCS  has  recently  been  accepted  as  International 
Standard  ISO/IEC  18025.  The  EDCS  places  environmental  features  into  one  of  several 
precisely-defined  environmental  concepts,  then  specifies  certain  values  or  enumerations  for  each. 
We  used  elements  of  the  EDCS  in  constructing  our  stakeholder  questionnaires.  However,  the 
level  of  detail  made  it  less  desirable  for  use  as  our  metadata  standard,  given  it  would  make  the 
initial  step  of  posting  a  database  very  time-consuming. 

The  second  similar  system  is  the  Master  Environmental  Library  (MEL),  which  is 
maintained  by  the  Defense  Modeling  and  Simulation  Office  (DMSO).  The  MEL  is  an  internet- 
based  library  of  terrain  resources  and  is  a  joint  repository  of  geospatial  data,  satellite  imagery  as 
well  as  terrain  databases.  It  is  a  “one-stop  site  for  ordering  environmental  information.”  The 
library  includes  some  terrain  databases,  but  the  majority  of  the  holdings  seem  to  work  as  a 
repository  of  satellite  imagery  and  specific  environmental  data,  which  would  be  used  to  build  a 
separate  terrain  database.  It  is  functionally  similar  to  the  concept  of  the  ADTL,  but  factors  make 
it  less  useful  to  analysts. 

The  MEL  uses  Federal  Geographic  Data  Committee  (FGDC)  Standards  as  its  metadata 
for  organization.  Like  the  EDCS,  those  FGDC  standards  are  incredibly  detailed.  Also  like  the 
EDCS,  they  can  discourage  an  individual  from  posting  a  database.  The  result  is  that  there  are  not 
many  terrain  databases  in  the  MEL. 
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Finally,  the  third  similar  system  is  the  Synthetic  Natural  Environment  (SNE)  Virtual  Data 
Repository  (SVDR).  It  has  the  same  purpose  as  the  ADTL,  but  at  this  point,  it  is  focused  on 
geospatial  products  for  00  S.  It  is  designed  to  be  a  virtual  repository  of  3 -dimensional  geospatial 
data  for  use  in  combat  modeling.  The  SVDR  is  still  under  development  by  the  Science 
Applications  International  Corporation  (SAIC)  in  conjunction  with/for  RDECOM.  Nonetheless, 
the  SVDR  has  great  potential  for  reuse  of  similar  functions  or  lessons  learned  in  implementing 
the  ADTL.  Individuals  involved  in  the  SVDR  development  have  been  instrumental  in  this  study. 

2.2  Stakeholder  Input 

Based  on  our  initial  research,  we  widened  our  set  of  stakeholders  to  that  portion  of  the 
modeling  and  simulation  community  that  deals  most  closely  with  terrain  databases.  A  complete 
list  of  organizations  who  were  contacted  is  shown  in  Appendix  B.  Our  first  contact  with  this 
wider  group  was  with  the  first  of  two  questionnaires,  followed  by  a  small  group  session. 

2.2.1.  Questionnaire  1 

We  distributed  the  first  questionnaire  in  October  by  electronic  mail  to  approximately  45 
individuals  from  the  organizations  listed  in  Appendix  B.  Those  contacted  were  asked  to  input 
their  responses  to  a  number  of  questions  on  a  web-based  form.  The  purpose  of  the  questionnaire 
was  twofold.  First,  we  wanted  to  further  gather  any  desired  functions  of  such  a  repository,  as 
well  as  provide  additional  evidence  of  its  value  for  the  community.  Second,  it  was  our  first 
chance  to  get  feedback  as  to  what  metadata  should  be  included  in  our  solution.  We  met  the  first 
of  those  objectives  completely;  for  reasons  listed  below,  we  had  limited  success  with  the  second. 
The  questionnaire  is  shown  in  Appendix  C;  the  raw  results  are  in  Appendix  D. 

Of  the  45  individuals  who  received  the  questionnaire,  19  responded.  (They  are  the  starred 
listings  in  Appendix  B.)  In  general,  they  all  classified  themselves  as  both  users  and  builders  of 
terrain  databases.  They  used  a  wide  range  of  simulation  models,  for  a  variety  of  purposes  and 
operational  scenarios.  None  used  them  for  simulation  of  aviation  assets,  and  in  general,  most 
were  focused  at  the  battalion  or  brigade-level  and  higher. 

Most  interesting  were  the  responses  regarding  their  own  libraries  of  terrain  databases. 
Fourteen  of  the  19  individuals  maintain  their  own  library  of  databases.  If  they  needed  a 
particular  database,  either  one  of  a  specific  location  or  one  with  particular  features  represented, 
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eight  of  the  19  would  take  the  time  to  build  a  new  database.  Finally,  of  the  19  responses,  17 
agreed  that  a  registry  or  repository  of  databases  would  be  useful,  but  they  desired  differing  levels 
of  functionality.  13  of  the  19  thought  the  registry  would  be  useful  if  it  provided  only  a  point  of 
contact  for  the  database;  17  of  19  agreed  it  would  be  useful  if  one  were  able  to  download  the  file 
directly  from  the  registry.  These  results  answered  our  question  of  the  value  of  the  system  to  the 
community.  Clearly  such  a  repository  would  help  individuals  in  the  field  as  they  accomplish 
their  tasks. 

This  question  of  accessibility  was  answered  by  COL  Stone  in  an  IPR.  In  order  to  maintain 
security  of  the  files,  he  specified  that  the  registry  would  only  list  the  point  of  contact  and  would 
not  be  a  direct  file  transfer. 

To  start  to  determine  the  significant  metadata,  we  asked  the  respondents  to  rank  order  19 
potential  metadata  fields  from  one  to  19,  with  one  being  most  important.  Unfortunately,  it  was 
not  possible  to  gain  any  specific  insight  because  the  form  allowed  respondents  to  list  more  than 
one  item  as  a  single  number.  As  a  result,  it  was  the  case  that  several  individuals  listed  more  than 
one  number-one-ranked  item.  Nonetheless,  investigating  the  results  further,  we  could  make 
some  generalizations  based  on  the  number  of  times  a  particular  item  was  ranked  among  the  top 
three.  In  particular,  14  respondents  listed  the  location  as  one  of  the  three  most  important  details; 
12  listed  the  simulation  platform  (the  format)  as  among  the  top  three  most  useful  piece  of 
information.  Those  results  are  not  surprising.  Beyond  that  analysis  though,  the  initial  cut  at  the 
metadata  was  not  as  productive  as  hoped. 

Many  respondents  added  their  own  comments  as  to  other  metadata  items  that  should  be 
included.  We  incorporated  those  comments  into  the  workshop  and  second  questionnaire.  The 
comments  can  be  grouped  into  questions  about  the  features  depicted  -  roads,  structures,  rivers  - 
and  about  the  detail  of  the  source  data.  That  input  helped  us  considerably  in  developing  the 
topics  for  future  discussions  with  these  stakeholders. 

2.2.2.  Workshop 

After  compiling  our  results  of  the  first  questionnaire,  we  felt  it  would  be  important  to 
attempt  to  gather  many  of  the  stakeholders  together  to  discuss  individual  items  of  metadata.  We 
did  this  in  a  small  group  setting  in  conjunction  with  the  Industry/Interservice  Training, 
Simulation  &  Education  Conference  (I/ITSEC).  Wanting  to  keep  the  forum  fairly  small,  we 
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invited  21  individuals,  and  eight  attended.  The  purpose  of  this  workshop  was  to  present  the 
results  of  the  first  questionnaire,  then  to  focus  the  discussion  on  the  metadata  elements  that 
would  be  important  for  inclusion.  The  format  of  the  meeting  also  would  allow  us  to  capture  the 
relative  value  of  each  item  of  metadata.  We  split  the  eight  individuals  into  two  groups.  Four  of 
the  individuals  were  given  the  results  of  the  first  questionnaire.  The  other  four  were  given 
samples  of  metadata  about  four  databases  from  the  MEL.  Both  groups  had  the  task  of 
identifying  which  elements  were  required,  which  were  redundant,  what  other  detail  is  needed, 
and  how  much  more  detail  should  be  listed. 

Group  1  presented  the  following  observations  shown  in  bulletized  form  below.  They  also 
recommended  giving  a  person  a  range  of  options  for  answering  the  questions,  for  example, 
whether  structures  are  represented  could  be  answered  as  “no”,  “in  2-dimensions”,  or  “in  3- 
dimensions”.  That  recommendation  was  included  in  the  second  questionnaire,  found  later  in  the 
report. 

•  Redundant  items 

o  Location  and  geographical  extent 
o  Multi-cell  and  single-cell 

•  Required  items 

o  Selection  of  a  naming  convention  for  Location 
Geographic  feature  (Fort  Hood) 

Center  of  Mass  (a  single  latitude  /  longitude) 

Boundaries  of  the  “box”  (lower-left  lat/long,  upper-right  lat/long) 
o  Format  (OTB,  Janus  version  x,  etc.) 
o  Application  (System,  or  Open  Flight,  etc.) 
o  Representation  (Grid,  TIN  or  other) 
o  Coordinate  system 

o  Source  data  with  resolution  (DTED  1,  2,  3,  HRTE  4,  5,  6) 

Lineage  {if  altered) 
o  Features  and  Attributes 

Are  road  networks  represented  (Yes  /  No) 

Are  structures  represented  (No  /  2D  /  3D) 

Is  vegetation  represented 
Are  soil  types  represented 


Group  2  identified  that  the  MEL  isn’t  completely  aligned  with  modeling  and  simulation 
products.  Further,  they  added  that  the  metadata  (FGDC  standards,  as  mentioned  earlier)  would 
likely  be  a  hindrance  to  anyone  posting  a  database  to  the  repository.  One  member  of  the  group 
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commented  that  having  more  than  about  six  metadata  elements  would  be  an  obstacle  for  him  to 
post  his  databases.  The  group  offered  that  a  hierarchical  structure  of  the  metadata  would  be 
required.  Finally,  they  added  that  it  would  be  useful  if  an  analyst  could  post  information  about  a 
database  after  using  it,  informally  adding  to  the  metadata  itself. 

They  identified  the  following  as  important  elements  that  are  included  in  the  MEL: 
(underlined  items  are  the  “headings;”  each  item  underneath  is  a  subordinate  element  of  that 
heading) 


Citation  Information 

o 

Originator 

o 

Publication  date 

o 

Title 

o 

Edition 

o 

Online  linkage 

o 

Publication  information 

o 

Publication  Place 

o 

Publisher 

o 

Other  Citation  Details 

Description 
o  Abstract 
o  Purpose 

o  Supplemental  Information 
o  Time  period  information  (publication  date) 

Spatial  Domain 

o  Bounding  Coordinates 
Keywords 

o  Theme  from  MELScientific-EngineeringFieldThesaurus 
o  Place  from  MEL  Location  Thesaurus 
o  Stratum  from  MELEnvironmentalDomainThesaurus 
o  Temporal  from  MEL_Temporal_Coverage_Thesaurus 
Access  Constraints 
Use  Constraints 
Browse  Graphic 
Point  of  Contact 
Entity  and  Attribute  Information 
o  Entity  and  Attribute  Overview 
Data  Quality  Information 
o  Completeness  report 


They  listed  the  following  items  as  not  needed: 


Publication  time 

Geospatial  Data  Presentation  Form 
Series  Information 
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•  Status 

•  Entity  and  Attribute  Detail  Citation 

Each  of  the  group’s  sets  of  feedback  was  significant  and  considered  for  inclusion  in  the 
second  questionnaire.  A  widely-voiced  theme  was  the  observation  that  the  amount  of  metadata 
required  to  post  a  database  would  be  the  key  question  for  the  success  of  the  ADTL.  It  was  and 
has  continued  to  be  observed  that  many  metadata  fields  will  result  in  a  very  productive  search  by 
any  analyst,  simply  because  they  could  search  on  any  of  those  fields.  However,  at  the  same  time 
it  was  clear  that  requiring  all  of  those  fields  of  information  to  be  entered  would  make  the  initial 
step  of  posting  a  database  prohibitive.  As  noted  earlier,  one  individual  specifically  said  that 
requiring  more  than  six  fields  would  lead  him  to  post  information  about  a  limited  number  of  his 
databases.  Since  the  success  of  the  library  is  based  on  those  two  factors,  they  became  our 
driving  force  for  evaluating  any  proposed  model  of  the  metadata.  Armed  with  that,  and  with  the 
more  detailed  set  of  potential  metadata  fields,  we  began  crafting  a  second  questionnaire.  This 
questionnaire  would  really  allow  us  to  model  a  candidate  solution  and  receive  feedback  on  the 
relative  merits  of  each  individual  field. 

Chapter  3:  Modeling  and  analysis 

The  modeling  and  analysis  conducted  for  this  study  is  not  precisely  aligned  with  the  usual 
application  of  modeling  and  analysis  envisioned  in  the  SEMP.  In  many  cases,  the  modeling  and 
analysis  step  is  the  point  at  which  the  performance  of  candidate  alternatives  is  measured  and 
analyzed.  Using  those  results  in  the  decision-making  step,  each  alternative’s  performance  is 
scored  according  to  the  relative  value  of  the  functions.  However,  in  this  study,  the  alternatives 
we  were  considering  were  items  to  be  included  as  part  of  the  metadata.  Therefore,  our  modeling 
effort  consisted  of  developing  a  list  of  metadata  items  and  allowing  our  stakeholders  to  express 
their  opinion  of  each.  The  functions  against  which  they  were  measured  were  the  relative  ease  of 
posting  a  database  and  searching  for  a  database.  Having  done  that,  it  fell  to  us  to  determine  how 
many  of  the  most  important  items  would  be  included  as  entries  required  of  someone  posting  a 
database. 
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3.1  Questionnaire  2 


Again  our  method  of  gathering  this  information  was  the  use  of  an  online  questionnaire. 
Similar  to  the  first  iteration,  we  distributed  an  invitation  to  participate  over  electronic  mail. 
However,  for  this  portion,  COL  Stone  drafted  a  memorandum  explaining  his  overall  purpose  in 
asking  for  the  input.  Prior  to  distributing  the  questionnaire  though,  we  conducted  more 
background  research  as  to  which  features  and  attributes  should  be  included  as  potential  elements. 

3.1.1.  F inding  the  right  features 

Our  first  questionnaire  and  the  workshop  we  held  provided  us  a  good  basis  for  many 
questions  about  the  levels  of  detail  of  information  that  could  be  included  (elevation  source  data 
resolution,  cultural  source  data  resolution,  etc.).  We  considered  these  a  sort  of  “marginal  data,” 
the  type  of  general  data  found  on  a  paper  map  that  provides  the  background  information  of  the 
map.  More  difficult  to  choose  were  which  features  should  be  included  as  potential  metadata 
items  -  a  sort  of  content  data.  Roads,  structures  and  vegetation  are  all  features.  But  we  could 
continue  listing  items  to  provide  as  much  added  detail  as  desired.  Other  features  could  include 
wells,  bridges  and  golf  courses.  Determining  where  to  draw  the  line  became  the  focus  of  our 
work.  Unfortunately,  there  are  many  different  standards  for  which  features  should  be  included  in 
terrain  databases.  The  FGDC  certainly  established  a  set  with  their  thematic  representation  of 
geospatial  data.  The  Digital  Geographic  Information  Working  Group  (DGIWG)  developed  their 
Features  and  Attributes  Coding  Catalog,  which  is  another  source.  Individual  software  developers 
have  also  established  their  own  set  of  what  features  “should”  be  included  in  any  database  of 
theirs.  Finally  the  Environmental  Data  Coding  Specification  (EDCS),  also  an  ISO  standard, 
provides  its  own  detailed  description  of  features.  In  the  end,  we  considered  each  of  the  first  three 
sources,  but  we  focused  on  the  EDCS.  In  selecting  these  elements,  we  reviewed  every 
environmental  concept  (EC)  defined  by  this  standard  and  selected  those  that  were  militarily 
relevant.  You  can  find  questionnaire  2  in  Appendix  E. 

3.1.2.  Results  of  questionnaire  2 

As  mentioned  above,  we  distributed  an  electronic  mail  message  from  COL  Stone  inviting 
55  individuals  to  respond  to  this  questionnaire.  The  questionnaire  itself  was  web-based.  The 
organizations  targeted  were  the  same  as  the  first  questionnaire,  with  some  additions.  The  list  of 
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organizations  is  shown  at  Appendix  F;  again,  those  who  responded  are  starred.  We  again  asked 
the  respondents  to  classify  themselves  as  builders,  managers,  or  users  of  terrain  databases.  We 
also  allowed  them  to  select  some  “other”  function.  We  received  28  responses  to  the 
questionnaire,  six  of  whom  were  builders,  four  were  managers,  seven  were  users,  and  1 1 
classified  themselves  as  other.  Of  those  categorizing  themselves  as  other,  the  responses  ranged 
from  someone  performing  all  of  the  above  functions  to  someone  who  develops  requirements  for 
the  simulation  systems. 

The  bulk  of  the  survey  was  taken  up  in  attempting  to  determine  the  best  set  of  metadata 
fields.  We  did  so  by  asking  the  respondents  to  classify  24  candidate  fields  as  Required,  Desired 
but  not  required,  and  Not  required.  There  was  no  limit  to  the  number  of  fields  that  could  be 
classified  as  required.  Appendix  G  describes  the  intended  meaning  of  those  fields,  and  you  can 
find  the  raw  results  of  these  questions  in  Appendix  H. 

Of  the  24  candidate  fields,  on  average  a  respondent  selected  17  of  the  fields  as  required. 
There  were  no  fields  that  were  unanimously  classified  as  required.  Likewise,  there  were  none 
unanimously  classified  as  not  required.  The  results  are  shown  in  the  table  and  accompanying 
figure  below. 
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Candidate  Field 

Required  Desired  Not  Required  %  Required 

Coordinate  System  Used 

27 

1 

0 

96% 

Location 

26 

2 

0 

93% 

Format 

26 

1 

0 

96% 

Roads 

24 

3 

1 

86% 

Vegetation 

24 

3 

1 

86% 

Elevation  Source  Data  w/Resolutioi 

23 

5 

0 

82% 

Topography  Representation 

22 

5 

1 

79% 

Structures 

22 

4 

2 

79% 

POC 

22 

4 

2 

79% 

Publication  Date 

21 

6 

1 

75% 

Cultural  features 

20 

6 

2 

71% 

Cultural  Source  Data  w/Resolution 

19 

8 

1 

68% 

Hydrology 

19 

6 

3 

68% 

Application 

18 

7 

2 

67% 

Soil  Types 

18 

8 

2 

64% 

Littoral 

18 

8 

2 

64% 

Lineage 

17 

8 

3 

61% 

Title 

17 

9 

2 

61% 

Utilities 

16 

9 

3 

57% 

Dynamic  Terrain 

15 

11 

2 

54% 

Atmospheric  Effects 

14 

9 

5 

50% 

System  reqts. 

14 

12 

2. 

50% 

Originating  Agency 

13 

10 

5 

46% 

SEDRIS-Compliant 

12 

13 

3 

43% 

Table  1:  Raw  results  from  Questionnaire  2 
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Additionally,  we  asked  respondents  to  comment  on  the  value  of  three  other  functions 
which  could  be  available  in  the  ADTL.  They  rated  them  from  one  to  five,  where  five  meant  they 
“strongly  agreed”  that  such  a  function  would  be  useful.  First,  they  were  asked  whether  it  would 
be  useful  for  users  to  “post”  opinions  or  additional  information  about  a  TDB  after  having  used  it. 
Of  all  respondents,  the  average  score  given  was  3.9,  and  eight  rated  it  a  5.  Second,  they  were 
asked  whether  it  would  be  useful  to  have  a  resource  to  send  an  email  to  other  members  of  a 
community.  All  respondents  rated  this  as  4,  and  1 1  rated  it  5.  Finally,  they  were  asked  whether 
it  would  be  useful  to  provide  additional  metadata  about  a  database  after  using  it.  Respondents 
rated  this  function  3.8  on  average,  and  10  rated  it  5. 

Based  on  our  discussion  in  the  small  workshop,  we  also  were  interested  in  how 
respondents  were  most  comfortable  describing  a  particular  location.  We  asked  if  they  would 
prefer  using  a  specific  Geographic  Place  Name  (i.e.  Fort  Hood),  the  center  of  mass  of  the  area 
represented  (latitude  /  longitude),  or  the  lower- left  and  upper-right  boundaries  of  the  area 
represented  (latitude  /  longitude).  A  large  majority,  19  respondents,  indicated  that  they  were 
most  comfortable  describing  an  area  by  its  boundaries. 
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3.2  Analysis  of  Results 


We  stepped  back  from  these  raw  results  and  wanted  to  analyze  them  while  considering  the 
overall  purpose  of  the  project.  It  is  critical  to  the  Systems  Engineering  and  Management  Process 
to  use  value-focused  thinking  in  analyzing  the  results  of  any  project.  As  we  did  this  for 
managing  terrain  databases,  we  returned  to  our  original  thoughts  on  the  functional  decomposition 
of  the  system,  as  well  as  the  importance  placed  on  the  number  of  metadata  fields  that  we  should 
select.  Finally,  COL  Stone’s  focus  on  the  end-user  of  these  databases  led  us  to  consider  the 
results  from  their  perspective.  We  considered  each  of  those  factors  as  we  began  to  analyze  the 
results  of  the  questionnaire  and  develop  our  recommendation. 

3.2.1.  Which  features  to  include 

As  mentioned  above,  COL  Stone  desired  that  we  strongly  consider  the  needs  and  values  of 
the  end  user  of  terrain  databases.  This  led  us  to  ask  respondents  on  the  questionnaire  to  classify 
their  roles  in  the  community.  However,  that  classification  is  not  perfect:  10  individuals 
classified  themselves  as  “other,”  and  some  of  them  stated  in  the  notes  that  they  actually 
performed  all  of  the  roles  listed.  Further,  terrain  database  builders  are  also  generally  database 
users  to  some  extent.  Therefore,  while  we  considered  users  separately,  we  did  not  completely 
discount  the  input  of  any  of  the  respondents.  Additionally,  the  observations  of  the  users  as  a 
group  are  not  dissimilar  to  those  of  the  rest  of  the  respondents. 

The  first  question  to  answer  was  the  number  of  metadata  fields.  Clearly  there  are  the  two 
competing  interests.  Requiring  more  fields  provides  more  data  and  would  make  the  results  of  a 
search  more  useful,  but  would  be  an  obstacle  to  easy  posting  of  information.  Fewer  fields  would 
be  easier  to  post  but  would  decrease  the  value  of  any  search.  We  began  to  answer  this  question 
by  recalling  the  observation  of  one  individual  at  our  workshop.  Specifically,  the  individual 
stated  that  having  any  more  than  six  metadata  fields  would  be  too  many  and  would  lead  one  to 
only  post  those  databases  that  were  required.  While  that  observation  was  not  universally  agreed- 
upon  at  the  workshop,  those  attending  generally  shared  the  same  opinion  in  terms  of  too  many 
fields  being  an  impediment  to  populating  the  repository.  On  the  other  hand,  one  key  result  of 
questionnaire  2  was  the  number  of  fields  that  were  selected  as  required  by  the  respondents.  As 
mentioned  above,  an  average  respondent  rated  17  fields  as  required.  Regardless  of  the 
observation  that  more  than  six  was  too  many,  in  practice  the  respondents  wanted  an  average  of 
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17.  Since  the  goal  of  the  study  was  to  find  a  reasonable  number  that  would  still  be  descriptive, 
six  and  17  became  our  boundaries.  Further,  since  it  is  important  to  promote  the  posting  of  the 
data,  remaining  closer  to  the  lower  bound  became  more  important  than  approaching  the  detail 
provided  by  17  fields. 

Although  that  thinking  led  us  to  a  range  of  values,  it  was  not  prescriptive  enough  to 
provide  a  specific  number  of  fields.  However,  by  investigating  the  responses,  it  became  possible 
to  determine  a  series  of  break  points  in  the  responses,  based  on  what  percentage  of  respondents 
rated  a  particular  field  as  required.  Further,  we  could  separate  the  user’s  responses  to  give 
another  perspective  on  the  problem.  We  used  both  of  these  techniques  to  develop  our 
recommendation. 

First,  we  considered  all  the  results  and  looked  for  natural  “break  points”  in  the  responses. 
In  a  perfect  scenario,  the  responses  would  follow  the  Pareto  principle,  which  holds  that  80%  of 
contribution  would  be  the  result  of  20%  of  the  fields.  More  generally  for  this  project,  that  a 
majority  of  the  respondents  would  select  20%  of  the  fields  as  necessary,  and  the  other  would  be 
considered  much  less  significant.  Unfortunately,  as  you  can  see  from  Graph  1 ,  there  was  no 
small  subset  of  fields  that  were  most  significant.  Rather,  many  of  the  fields  were  identified  as 
important.  Though  there  is  a  small  break  point  at  79%,  that  by  itself  does  not  allow  us  to  assess 
all  those  above  79%  as  required  and  those  below  as  unimportant.  To  make  a  better  decision,  we 
considered  the  responses  of  those  who  classified  themselves  as  users  of  these  databases.  The 
results  of  those  seven  individuals  are  summarized  in  the  table  and  graph  below. 
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Candidate  Field 

%  Required 

Coordinate  System  Used 

100% 

Location 

100% 

Format 

100% 

Topography  Representation 

100% 

Application 

100% 

Elevation  Source  Data  w/Resolution 

86% 

POC 

86% 

Roads 

71% 

Vegetation 

71% 

Structures 

71% 

Publication  Date 

71% 

Cultural  features 

57% 

Cultural  Source  Data 

57% 

Hydrology 

57% 

Soil  Types 

57% 

Dynamic  Terrain 

57% 

Littoral 

43% 

Lineage 

43% 

Title 

43% 

Utilities 

43% 

Atmospheric  Effects 

43% 

System  Requirements 

43% 

SEDRIS-Compliant 

43% 

Originating  Agency 

29% 

Table  2:  “User”  results  from  Questionnaire  2 
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User  %  Required 


100% 

80% 

60% 

40% 

20% 

0% 
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Figure  4:  “User”  results  from  Questionnaire  2 

Looking  at  the  responses  from  users,  there  are  some  clearer  break  points  in  the  data.  The 
importance  of  the  first  five  fields  is  clear,  since  they  were  unanimously  rated  as  required.  That 
also  provides  the  first  break  point,  between  those  rated  as  required  by  all  users  and  those  rated 
required  by  86%  (six  of  the  seven  users).  The  break  points  are  distinct  in  the  graph  above.  At 
the  same  time  though,  merely  choosing  those  fields  that  all  users  selected  as  required  would  give 
their  input  more  weight  than  intended.  However,  using  their  choices  as  a  starting  point  and  still 
considering  the  input  of  all  other  respondents  allowed  us  to  make  a  recommendation  of  which 
fields  should  be  included  for  the  repository.  Further,  using  the  format  of  a  required  set  and 
optional  set  of  fields  allows  us  to  strike  a  balance  between  the  detail  desired  and  difficulty  of 
posting  the  information. 

As  a  result  of  this  thinking,  we  returned  to  the  initial  importance  of  the  user’s  opinion  on 
COL  Stone.  Users  of  terrain  databases  -  analysts  from  around  the  Army  -  would  be  the 
benefactors  of  this  system,  and  therefore  we  selected  those  fields  that  they  unanimously  rated  as 
required.  That  gave  us  five  fields:  coordinate  system  used  in  the  database,  location  represented, 
format  of  the  database,  type  of  topographic  representation,  and  the  application  of  the  database. 
(For  a  complete  explanation  of  all  the  fields  listed  in  this  study,  see  Appendix  G.)  It  is  also 
significant  that  more  than  90%  of  all  other  users  rated  the  first  three  of  these  as  required.  71% 
and  52%  rated  the  type  of  topographic  representation  and  application  as  required.  Choosing 
these  fields  as  required  in  the  repository  met  the  requirement  of  catering  to  the  needs  of  the  users 
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of  terrain  databases.  However,  we  felt  it  did  not  adequately  represent  the  needs  of  others  in  the 
field. 


To  address  the  needs  of  those  other  respondents,  we  considered  the  fields  that  they  felt 
were  most  important.  Looking  again  at  Graph  1  above,  there  are  three  candidate  fields  that  more 
than  80%  of  other  respondents  selected  as  required:  whether  vegetation  is  represented  (90%  of 
other  respondents),  the  detail  of  the  elevation  source  data  (90%),  and  whether  roads  are 
represented  (81%).  Also  significant  is  the  fact  that  more  than  70%  of  our  users  rated  these  as 
required.  As  a  third  measure  of  usefulness,  only  the  question  of  roads  was  selected  as  not 
required  by  more  than  25%  of  the  users.  Therefore,  these  three  added  candidate  fields  became 
part  of  the  recommended  required  set  of  metadata.  Finally,  the  point  of  contact,  while  not 
universally  accepted  as  required  by  the  respondents,  must  be  included  as  part  of  the  metadata, 
since  that  is  the  method  of  file  transmission. 

To  obtain  the  list  of  optional  fields,  we  applied  a  similar  approach.  In  general,  these 
optional  fields  provide  more  of  the  “content”  detail  about  a  database,  and  consist  largely  of  yes 
or  no  questions.  Our  desire  was  to  find  the  next  set  of  pertinent  facts  about  a  database,  as 
identified  by  our  respondents.  To  do  so,  we  selected  items  that  were  designated  as  required  by 
more  than  60%  of  the  respondents.  The  associated  results  are  summarized  in  Table  3  below. 


Overall  % 

User  % 

Other  % 

Required 

Required 

Required 

Structures 

79% 

71% 

81% 

Publication  Date 

75% 

71% 

76% 

Cultural  features 
Resolution  of  Cultural 

71% 

57% 

76% 

Source  Data 

68% 

57% 

71% 

Hydrology 

68% 

57% 

71% 

Soil  Types 

64% 

57% 

67% 

Littoral 

64% 

43% 

71% 

Lineage 

61% 

43% 

67% 

Title 

61% 

43% 

67% 

Dynamic  Terrain 

54% 

57% 

52% 

Table  3:  Metadata  recommended  as  optional 
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3.2.2.  Which  functions  to  include 

Our  next  question  was  to  determine  which  of  the  other  proposed  functions  were  deemed 
worthy  of  including  as  part  of  the  repository.  There  were  three  options  considered.  The  first  of 
these  was  the  capability  of  any  individual  to  send  an  electronic  mail  message  to  a  number  of 
other  people  in  the  field.  This  is  normally  referred  to  as  an  email  reflector.  This  sort  of  function 
is  widespread  across  the  military  as  a  valuable  method  of  getting  detailed  information,  especially 
when  the  community  is  geographically  dispersed.  For  each  of  these  results,  a  score  of  5  means 
that  the  respondent  “strongly  agreed”  that  the  function  would  be  useful.  For  the  question  of  the 
email  reflector,  all  respondents  rated  it  as  4,  and  all  users  rated  it  4.43.  Given  that  high  rating, 
we  recommended  including  that  function  in  the  repository. 

The  second  function  considered  was  the  capability  to  allow  individuals  to  post  comments 
or  additional  information  about  a  database  after  they  had  worked  with  it.  This  is  separate  from 
the  capability  to  add  to  the  metadata.  Instead,  this  represents  the  ability  to  provide  notes  about  a 
database  which  would  be  visible  to  any  other  user.  The  goal  of  doing  so  is  to  allow  these 
individuals  to  amplify  the  description  of  a  particular  database,  but  not  have  to  confirm  the 
validity  of  the  comment.  Respondents  rated  their  agreement  that  this  function  would  be  useful  as 
3.89.  Again  the  users  of  databases  rated  it  higher,  at  4.14.  Based  on  these  results,  we  also 
recommended  including  that  function  in  the  repository. 

Finally,  the  third  function  considered  was  the  ability  for  individuals  to  add  information  to 
the  actual  metadata  of  a  terrain  database.  The  previously  discussed  function  would  merely  add  a 
set  of  comments  about  a  database;  this  function  would  allow  people  to  actually  change  the 
metadata  of  a  database.  The  goal  of  this  is  again  to  provide  a  more  accurate  metadata  than  would 
be  provided  at  the  initial  step  of  posting  a  database.  Although  the  responses  were  similarly 
positive  to  this  idea,  we  did  not  recommend  including  this  function.  We  decided  that  because 
allowing  that  sort  of  modification  to  the  metadata  would  impose  an  additional  restriction  that  the 
“updated  metadata”  would  have  to  be  validated  by  the  original  individual  posting  the 
information.  Having  that  requirement  would  be  very  time-consuming,  especially  to  the  original 
person  posting  the  information.  It  also  could  lead  to  confusing  information  about  a  database,  if 
there  were  several  different  entries  for  one.  Finally,  it  is  possible  that  a  person  using  a  database 
would  be  wrong  about  the  metadata  in  the  first  place.  For  each  of  those  reasons,  we  decided 
against  recommending  that  it  be  included  in  the  repository. 
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Chapter  4:  Current  and  future  work 

After  this  research,  we  have  recommended  the  metadata  and  functions  that  should  be  used 
to  organize,  manage  and  search  to  the  terrain  databases  in  the  ADTL.  Having  completed  that, 
there  are  at  least  three  more  phases  required  to  implement  the  recommendations  and  have  a 
useful,  valuable  repository.  First,  we  have  begun  populating  the  library  with  a  trial  set  of 
locations.  Second,  after  capturing  the  lessons  learned  from  that  initial  population,  the  call  needs 
to  go  out  to  the  rest  of  the  community  to  populate  the  repository  with  their  databases.  Finally, 
there  needs  to  be  a  plan  for  and  organization  responsible  for  managing  the  ADTL. 

We  have  already  begun  the  first  of  these  steps,  populating  the  library  with  an  initial  set  of 
terrain  databases.  COL  Stone  has  directed  that  we  contact  representatives  from  Forts  Hood, 

Riley  and  Knox  to  have  them  input  information  about  the  terrain  databases,  and  we  are  in  the 
process  of  doing  so.  We  have  also  been  in  contact  with  individuals  from  RDECOM  and  ERDC- 
TEC,  who  will  also  provide  this  information  about  databases  they  possess.  This  initial  step  of 
implementation  will  not  only  begin  to  gather  the  information  required  for  the  ADTL,  it  will  also 
allow  individuals  from  around  the  Army  to  further  refine  the  metadata  selected.  As  described 
earlier,  the  SEMP  is  an  iterative  process,  and  while  the  metadata  for  the  ADTL  will  at  some 
point  have  to  be  set,  we  are  still  open  to  suggestions  for  slight  modifications  that  will  improve 
the  system. 

Following  this  initial  step  of  collecting  information  from  a  limited  number  of  installations 
and  organizations,  the  ADTL  will  become  widely-available.  Once  in  place,  there  will  be  a  call 
for  any  and  all  organizations  to  post  information  about  terrain  databases  they  have  on  hand.  This 
will  also  signal  the  opportunity  for  other  individuals  to  use  the  ADTL  to  find  terrain  databases 
that  they  would  like  to  use.  That  will  lead  directly  to  the  long-term  management  and 
organization  of  the  repository.  Not  least  of  the  issues  to  address  at  that  point  will  be  the  question 
of  security  and  accessibility  of  the  databases. 

There  is  clearly  still  work  to  be  done  before  the  Army  Digital  Terrain  Library  becomes  a 
widely-used  and  valuable  resource  for  the  modeling  and  simulation  community.  In  this  study, 
we  have  focused  on  the  metadata  and  functions  required  to  make  that  repository  worthwhile  for 
the  experts  in  the  field.  By  studying  the  pertinent  background  facts  about  terrain  databases  and 
the  other  related  efforts  already  underway,  and  by  gathering  a  great  deal  of  input  from 
stakeholders,  we  have  recommended  a  set  of  metadata  and  functions  for  use  in  the  ADTL. 
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Ultimately,  this  recommendation  will  lead  to  an  important  resource  for  trainers  and  analysts 
around  the  Army  who  rely  on  terrain  databases  to  increase  the  realism  and  validity  of  their 
modeling  and  simulation. 
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Appendix  A,  Acronyms 


ADTL  Army  Digital  Terrain  Libra 


AGDIMP  Army  Geospatial  Data  Integrated  Master  Plan 


AMSO  Army  Modeling  and  Simulation  Office 


ATEC  Army  Test  and  Evaluation  Command 


BCSE  Battle  Command,  Simulation  and  Experimentation  Directorate 


BCTC  Battle  Command  Training  Center 


CGF  Computer-Generated  Force 


CTSF  Contractor  Test  Support  Facili 


DFDD  Digital  Feature  Data  Dictiona 


DGIWG  Digital  Geographic  Information  Working  Grou 


DMSO  Defense  Modeling  and  Simulation  Office 


DTED  Digital  Terrain  Elevation  Data 


DTOP  Digital  Topographic  Data 


DTRA  Defense  Threat  Reduction  Agenc 


EC  Environmental  Class 


EDCS  Environmental  Data  Coding  Specification 


ERDC  Engineer  Research  and  Development  Center 


FACC  Features  and  Attributes  Coding  Catalo 


FGDC  Federal  Geographic  Data  Committee 


FCS  Future  Combat  System 


TTTepr  Interservice  /  Industry  Training,  Simulation  and  Education 

11  1  OD'-/  n  n 

Conference 


IPR  In-Progress  Review 


ISO  /  IEC  International  Organization  for  Standardization  /  International 

Electrotechnical  Commission 


JCATS  Joint  Conflict  and  Tactical  Simulation 


JFCOM  Joint  Forces  Command 


J-GES  Joint-Geospatial  Enterprise  Services 


LSI  Lead  System  Integrator 


MANSCEN  Maneuver  Support  Center 


MEL  Master  Environmental  Libra 


MGRS 

Military  Grid  Reference  System 

NGA 

National  Geospatial  Intelligence  Agency  (formerly  National  Imagery 
and  Mapping  Agency,  NIMA) 

NGIT 

Northrup  Grumman  Information  Technology,  Inc. 

NSC 

National  Simulation  Center 

oos 

Objective  One-Semi-Automated  Force 

PEO-STRI 

Program  Executive  Office  for  Simulation,  Training  and 
Instrumentation 

PM 

Project  Manager 

RDECOM 

Research,  Development  and  Engineering  Command 

SBL 

Soldier  Battle  Lab 

SNE 


SVDR 


TDB 


TEC 


TIN 


TPIO 


TRAC 


TRADOC 


TSM 


UAMBL 


USACE 


USMA 


WSMR 


Synthetic  Environment  Data  Representation  and  Interchange 
Specification 


Synthetic,  Natural  Environment 


SNE  Virtual  Data  Reposito 


Terrain  Database 


Topographic  Engineering  Center 


Triangulated  Irregular  Network 


TRADOC  Product  Integration  Office 


TRADOC  Analysis  Center 


US  Army  Training  and  Doctrine  Command 


TRADOC  System  Manager 


Unit  of  Action  Maneuver  Battle  Lab 


US  Army  Corps  of  Engineers 


United  States  Military  Academ 


White  Sands  Missile  Range 


Appendix  B,  Organizations  Targeted  by  Questionnaire  1 

Stars  represent  organizations  who  provided  a  response  (some  had  more  than  one 
individual  respond) 

SBL* 

US  Army  ERDC* 

NSC* 

PM  FCS* 

FCS  LSI* 

MANSCEN* 

Boeing* 

DTRA* 

TRADOC  Futures  Center* 

PEO  STRI* 

TPIO- Virtual* 

TPIO-Terrain  Data 
NGIT 

TRAC-Monterey 
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Appendix  C,  Questionnaire  1 


1 .  Name ! 


2.  Organization  1 

3.  Email  address  i 

4.  Phone  number 

5.  Position  in  organization  1 


6.  Purpose  of  your  organization  i 

7.  How  do  you  use  terrain  databases? 


Build 
For  use  in: 


r 


Use 


f  Analysis  Training 

r~  r~  i  " 

Wargames  Other i 


8. 


t  of  the  time? 


E 

OneSAF 

C  WARSIM 

^  CombatXXI 

c 

c 

IUSS 

C  JANUS 

C  JCATS 

□ 

o 

CD 

9.  Which  types  of  forces  do  you  focus  on? 

. 

Dismounted  Mounted  Aviation 


Other 


I  WARS 
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10.  Which  echelon  of  forces  do  you  focus  on? 


Brigade  or  higher  ^  Battalion  u  Company 

r”1  p  f 

u  Platoon  or  lower  Other  1 

1 1 .  What  types  of  scenarios  do  you  focus  on? 


I™  r*  r"  r* 

Urban  Jungle  Desert  Forest 


* 

r  Other 

jj _ 

12.  What  types  of  operations? 

High-intensity  conflict?  Low-intensity  conflict  Peacekeeping 

operations 


13.  Is  there  a  particular  region  of  the  world  you  use  more  frequently  than  any  other? 


15.  Do  you  maintain  a  set  or  catalog  of  terrain  databases  for  these  purposes? 

u  Yes  ^  No 

16.  If  you  needed  a  terrain  database  for  a  particular  geographic  location,  how  would  you  get  it? 
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Contact  a  colleague 


Build  it  myself 


r 


r 


r  Other 

17.  Would  you  find  it  useful  to  have  a  “registry”  of  terrain  databases? 

L  Yes^  No 

18.  Would  such  a  registry  be  adequate  if,  after  searching,  it  provided  the  name  and  email  address 
of  a  person  or  organization  with  the  terrain  database  you’re  looking  for? 

u  Yes 


Why? 

19.  Would  such  a  registry  be  adequate  if,  after  searching,  it  provided  not  just  the  name  and  email 
address  of  a  person  or  organization,  but  also  provided  a  location  from  which  you  could  download 
the  database  itself? 

C  Yes  C  No 


Why?  Ill 

20.  Please  rank  the  following  attributes  of  such  a  registry  in  terms  of  their  importance  to  you  (1 : 
least  important  — >  4  most  important) 

*  Accessibility  (how  you  could  get  to  the  registry) 

!  Ease  of  database  distribution  (how  you  would  get  a  particular  database) 

Ease  of  data  entry/upload  (for  you  to  populate  a  registry  with  your  databases) 
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I  Level  of  detail  required  for  an  accurate  search  (how  specific  your  search  terms  could  be  to 
find  a  particular  database) 

21.  If  you  had  to  search  for  a  terrain  database,  what  characteristic  would  be  easiest  for  you  to 
search  according  to?  Please  rank  the  following  19  characteristics  for  their  “ease  of  use”  in 
characterizing  a  terrain  database.  A  rank  of  1  means  it  is  the  most  descriptive  characteristic;  a 
rank  of  19  means  it  is  the  least  descriptive  characteristic. 


Location 


Simulation  platform  /  format 


Date  created 


Lineage 


Application  (Ground,  Flight  simulation,  Mission  planning) 
Database  type  (Visual,  SAF,  PVD,  Radio,  Environment  Mgr) 
Geotypical  (notational)  or  geospecific 
Geographic  extent  (km) 

File  size  (GB) 

Source  (DTED-2,  DFAD,  ITD,  SEDRIS) 


Status  (available  or  under  development) 


Classification 


Database  generation  tools  used 
Export  format  (SEDRIS,  CTDB,  SI 000) 
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Platform  (PC-based,  SGI,  ESIG,  Motorola) 


Release  Authority 


Technical  POC 


1  Notes  (defaults  added) 

22. 1  know  that  there  are  countless  variations  for  the  content  of  a  terrain  database.  I'm  trying  to 
capture  the  most  significant  and  common  variations  and  would  appreciate  your  input  as  to  which 
those  are.  For  example,  it's  important  to  know  how  a  database  characterizes  soil  composition, 
since  there  are  several  possible  methods  to  do  so.  So  at  least  initially,  the  method  used  to 
describe  soil  composition  should  be  part  of  this  metadata.  Again,  I  know  that  this  list  could  be 
several  thousand  lines  long;  I'm  looking  for  the  most  important  subset  of  that. 


23.  If  you  have  any  other  thoughts,  questions  or  suggestions  for  this  project,  I  would  appreciate 
that  input.  Thank  you  again  for  your  time. 


'■A. 
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Appendix  D,  Results  of  Questionnaire  1 

A  response  of  “ON”  represents  that  the  respondent  selected  that  choice.  We  have 
identified  the  responses  by  a  number,  rather  than  individual’s  names.  It  is  possible  (and  did 
occur)  for  a  respondent  to  not  enter  some  information,  in  which  case  the  block  is  empty.  These 
results  are  organized  in  sections  to  make  the  reading  clearer. 


How  do  you  use  Tl 

DBs? 

Resp. 

ID 

Build 

Use 

For 

Analysis 

For 

Traininq 

For 

Warqames 

Some 

other 

use 

What  is  the  other  use? 

1 

ON 

2 

ON 

ON 

ON 

ON 

ON 

3 

ON 

ON 

4 

ON 

ON 

ON 

ON 

ON 

ON 

Experimentation 

5 

ON 

ON 

ON 

ON 

6 

ON 

ON 

ON 

ON 

ON 

ON 

C4ISR 

7 

ON 

ON 

ON 

ON 

ON 

Live,  virtual  and 
constructive  simulation 
venues 

8 

ON 

ON 

ON 

ON 

9 

ON 

ON 

ON 

10 

ON 

ON 

ON 

ON 

11 

ON 

ON 

ON 

12 

ON 

ON 

ON 

ON 

ON 

simulation 

13 

ON 

14 

ON 

ON 

ON 

Training  Development  & 
Training  by  exception  (Real 
World  Ranger  BN  type 
events) 

15 

ON 

ON 

ON 

ON 

ON 

ON 

Battle  Command  Systems 

16 

ON 

ON 

ON 

ON 

Routing  for  Unmanned 
Systems 

17 

ON 

ON 

ON 

18 

ON 

ON 

ON 

ON 

tactical  decision  aids, 
research 

19 

ON 

Look  at  how  space 
systems  collect  information 
to  buld  terrain  databases, 
and  how  that  information  is 
distributed. 

Resp. 

ID 

Most  Frequently 
Used  Software 

Other  Software  Type  Used  but  not  listed 

1 

Other 

My  focus  is  not  on  building  databases  for  simulation  and  training. 

2 

Other 

3 

Other 

CCTT  and  AVCATT 

4 

Other 

WALTS,  JSAF,  IMPACT,  HPAC,  IMEA 

5 

JANUS 
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6  Other 


Other 


OneSAF 


OneSAF 


10  JANUS 


1 1  Other 


12  OneSAF 


13  Other 


14  Other 


15  OneSAF 


16  OneSAF 


17  Other 


18  OneSAF 


19  Other 


OneSAF,  JointSAF,  JWARS 


OF  OTB  (OneSAF  is  not  a  fielded  system,  although  we  are  a  beta  test 
site,  currently  on  build  22  -  your  questionaire  is  flawed  in  this  regard), 
also  enable  use  of  ATCOM,  Firesim,  EADSIM,  CMS2,  SLAMEM, 
WECAM,  ALOES  (BLCSE  Federates) 


multiple 


At  this  point,  I  am  only  building  databases  so  I  do  not  spent  much  time 
using  the  simulation  itself 


BBS,  CBS,  JCATS,  JANUS,  SPECTRUM 


JCATS  &OF  OTB 


WARSIM,  OneSAF,  Combat  XXI  currently,  eventually  CTIA,  OneTESS, 
CCTT  and  AVCATT 


Aviation 


Types  of  forces  simulated 


Forces  Focus 
Other 

Focus  Other  Text 

ON 

1  work  in  an  R&D  environment 
where  we  are  trying  to  build 
basic  tools  to  help  with  terrain 
data  generation  and  database 
management.  Do  not  tailor  our 
work  to  a  specific  force.  We  do 
have  some  staff  working  closely 
with  the  SOF,  but  1  am  not  one 
of  them. 

CBRNE  effects  on  all  forces 
including  civilians 


I  assisted  my  supervisors  in 
building  databases  for  OOS, 
which  is  a  simulation  that 
focuses  on  brigade  and  below 
echelons. 


varies  based  on  needs  of 
requestor 


Infantry  with  combined  arms 
effects 
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We  look  at  the  combined  force. 


Echelon  simulated 


Scenario  used  most 


ID 

Echelon 

simulated 

1 

Other 

2 

Other 

3 

Other 

6  Other 


9  Other 


10  Other 


Scenario 

Focus 

Other 

Scenario 

ON 

1  have  been  focusing 
on  broad  area 
mapping  tools  -  not 
specific  to  urban, 
jungle,  desert,  or 
forest 

ON  ON  ON  ON  ON 


Although 
historically 
focused  on 
BDE  and 
Below  (down 
to  individual 
soldier), 
recently  has 
been 

expanded  to 
include  BDE 
and  above 


11  Other 


I  used  to 
work  in  the 
OneSAF 
program  and 
now  I  work 
forWARSIM. 


ON 

Complex  terrain  such 
as  the  mountainous 
regions  of  the 

Caspian  Sea  area 

ON 

build  data  for  use  in 
very  high  resolution 
to  large  joint 
experiments 

ON 

Geographically  large 
TDBs  that  end  up 
with  all  of  it  (urban 
canyons,  rolling 
terrain,  agriculture, 
constricted/mountain 
ous,  etc) 

ON 

It  varies  with  the 
experiment. 

ON 

combination 

ON 

At  this  point  1  am 
working  with  the 

CCTT  P2  database 
(NTC)  which  is  a 
desert  scenario. 
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OneSAF  is  a 
brigade  and 
below 
simulation 
while 

WARSIM  is  a 
higher 
echelon 
simulation. 


BDE  and 
below 


ON 

ALL 

ON 

Heavy  focus  on 
urban  but  all  are 
included 

17  Other 


WARSIM- 
Division  to 
Echelon 
above  Corps, 
OneSAF- 
Brigade  and 
Below 


ON 

ON 

ON 

ON 

ON 

ON 

ON 

ON 

ON 

All  of  the  above  as 
defined  by 
OneSAF/WARSIM 
data  model 

ON 

a  variety  of  scenarios 
to  test  environmental 
effects 

Types  of  Operations 


ID  HIC  Lie 


2  ON 


3 


Peacekeepin 


5 

ON 

6 

ON 

What  other  types  of  operations? _ 

Again,  I  myself  do  not  directly  support  individual 
units  or  build  databases  for  specific  types  of 
operations.  However,  TEC  does  have  workunits 
dedicated  to  feature  extraction  in  an  urban 
environment  and  tactical  decision  aids  in  an 
urban  environment.  Urban  conflict  is  seen  as  a 
research  area  where  much  work  needs  to  be 
done. 


Terrorist  attack  response,  Industrial  accidents 


All  purposes 


8 


9  ON 


10  ON 


11 


12  I  ON 


13 


it  varies  with  the  experiment. 


ALL,  including  Homeland  Securit 
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14 


15 


16 


17 


18  ON 


19  ON 


All  of  the  above 


Resp. 

ID 


Location 

Region  of 
World 

Reason  for  Region  of 
World 

If  you  need  a  database 


Would 
you  use 
some 

other  What  other 
means?  means? 


Not  Really, 
It  depends 
on  what 
the 

customer 

wants 


Middle 

East 


Southwest 

USA. 


Caspian 

Sea 


No,  We 
have  built 
the  world 
at  a  very 
low 

resolution 
and  then 
build 
higher 
resolution 
inserts  of 
the  AO  I 


Most  of  the 
last  3  years 
has  been 
spent  over 
Azerbaijan, 
with  some 
work  in 
CONUS 


It  depends  on  what 
the  customer  wants 


OEF/OIF 


Primary  area  used  for 
JFCOM  distributed 
training  and 
experimentation 
events. 


Scenario  used  in 
CGSOC 


Yes 

Yes 

Yes 

Yes 

No 

Yes 

No 

Yes 

Yes 

Yes 

Yes 

No 

Yes 

Yes 

No 

Yes 

Utilize 
databases 
provided  by 
CGSOC 


To  play  multiple 
exercises  all  over  the 
world  at  once  in 
networked 
environment 


DPG/FCS  scenarios 
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and 

elsewhere 


point  I  am 
working  on 
P2, so  I 
would  say 
the  area  at 
Ft  Irwin 


Caspian 

Sea 


13  no 


Current  opns  focus  to 
incorporate  lessons 
learned. 


TRADOC  approved 
scenario 


I  am  working  with  the 
conversion  of  a  P2 
(CCTT  NTC) 
database  to  an  OTF 
(OOS  terrain  format 


Our  users  are  from 
different 

organizations  all  over 
the  world 


Yes 

Yes 

No 

No 

No 

Yes 

Yes 

No 

No 

Yes 

No 

No 

No 

Yes 

No 

No 

Yes 

Yes 

Yes 

No 

Yes 

No 

Yes 

Yes 

Most  of  our 
scenarios 
use  DPG 
compliant 
scenarios 


SWA 


MidEast 

Germany 

Central 

America 


Southwest 

Asia, 

17  CONUS 


Past,  Present,  and 
Future  conflicts 


SWA  is 

temporary/intermittent 
for  current  conflicts. 

CONUS  is  ongoing 

for  home  station 

training.  Yes 


depends  on 
simulation 


Would  get 
source  code 
and  already 
built 

databases 

from 

whomever 
and  modify 
accordingly 
to  suit  our 
requirements 
typically 
requires 
development 
of  high  fidelity 
urban  areas 
to  include 
MES. 


First  resort 
would  be  to 
survey  the 
community 
for  existing 
TDB  meeting 
requirements, 
or  build  a 
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new  one  as 
last  resort 
depending  on 
urgency  of 
requirmeent. 


18 

No 

19 

No 

Yes 

Yes 

No 

Yes 

No 

Yes 

No 

No 

Would 

a  Would  it  be 

registry  useful  if  it 
be  provided 
useful?  only  POC? 


Why  or  why  not? 


Value  of  reqist 


Would  a 
registry  that 
allowed  you  to 
download  a 

t?  TDB  be  useful? 


It  would  help  TEC  be 
more  efficient.  We 
would  not  have  to 
dedicate  resources  to 
build  products  that 
already  exist.  It  would 
also  allow  us  to 
value-add  to  these 
products  as  opposed 
to  building  all 
datasets  from 
scratch.  This  also 
increases  efficienc 


If  such  a  resitry 
existed  and  the  POC 
info  was  provided  that 
would  be  helpful  but 
not  operationlly 
adeqaute. 


So  you  could  contact 
the  POC  and  get  it. 


It  could  take  too  long 
to  get  the  database 
and  compatibility  can 
be  an  issue.  Often 
the  person  identified 
is  on  travel  or  no 


Why  or  whv  not? 


I  think  the  ability  to  download 
the  database  would  have  to  be 
crucial  to  success.  Otherwise, 
efficiency  is  compromised  if 
CDs  have  to  be  burned  or 
FedExed.  What  would  even  be 
better  is  if  we  could  work  with 
the  data  directly  without  even 
downloading  -  such  as  in  a 
distributed  Internet 
environment.  More  and  more 
GIS  software  is  moving 
towards  an  enterprise 
environment  where  the  data  is 
distribute  across  a  network. 
Downloading  all  this  data  may 
be  very  time  comsuming. 
However,  if  you  can  access  the 
data  remotely  and  work  with  it 
at  your  PC,  that  would  be  the 
paradigm  I'd  move  towards. 
Something  like  ArcIMS. 


One  wouldn't  have  to  wait  for 
the  POC  to  be  in  the  office. 
Transfer  device  compatilibility 
is  no  longer  an  issue. 
However,  both  offices  need 
decent  size  communication 


42 


5  I  Yes  |  Yes 


longer  in  the  same 
position.  Many 
databases  are  larger 
than  what  can  be  put 
on  a  CD  or  even 
DVD.  Often  such 
databases  need  to  be 
shipped  via  a  hard 
drive.  The  databases 
could  be  on  a  UNIX 
or  SGI  machine 
supporting  one  office, 
but  the  requesting 
office  needs  the 
database  on  a 
Windows  machine. 
Providing  the  data  on 
a  compatible  transfer 
medium  can  be  a 
roblem. 


The  key  is  the  ability 
to  transfer  that  data 
base  through  the 
appropriate  electronic 
means  (classified 
versus  unclassified). 
The  NIPRNET  and 
SIPRNET  pipes  are 
very  limited. 


I  have  a  large  set  of 
terrain  data  that  I 
provide  for  others  to 
obtain.  I'm  the  POC 
for  OneSAF  terrain. 
See: 

http://mel.dmso.mil 
Select  HTML  Query 
Set  Data  Source  TEC 
-  USACE  Set  number 
of  records  to  display 
at  100  Select  Begin 
Data  Query  Visualize 
Bounding  areas 
shows  the  areas  that 
I  distribute  and 
Alternative  Access 
provides  a  means  to 
order  data 


You  really  need  a 
"Maybe"  choice. 
There's  sometimes 
more  to  this  than  just 
contacting  who  has  it 
on  disk.  There  may 
be  distribution 
restrictions  on  the 


pipes  to  download  a  large 
database,  typically  overnight. 
Comments  on  Question  21 
below:  The  metadata 
associated  with  such  a  registry 
are  the  key  to  making  it  work 
and  all  the  attributes 
mentioned  are  of  interest. 
However,  I  don’t  see  myself 
searching  on  many  of  those 
attributes,  so  I  only  ranked  the 
items  I  thought  I  might  use  in  a 
search. 


See  answer  to  question  18. 


Web  pages  are  needed  on 
both  classified  and  unclassified 
systems.  An  email  alone  would 
not  be  good  as  people  change 
jobs  and  the  link  to  the  data  is 
lost. 


Again,  depending  on  17  and 
comments  provided  in  18  -  but 
certainly,  ease  of  access  would 
increase  probability  of 
subsequent  use  if  the  TDB  met 
requirements.  COMMENT  on 
20  -  you  assume  that  there  are 
many  databases  that  are  of 
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13 

Yes 

Yes 

14 

Yes 

Yes 

15 

Yes 

Yes 

16  Yes 


17  Yes 


source  used,  on 
components  of  the 
product  itself,  etc. 

This  is  before  you 
examine  #17,  which 
is  why  it  may  not  be 
useful,  which  would 
then  make  18  and  the 
following  questions 
below  a  moot  point. 


we  would  need  to 
know  about  the  data, 
its  resolution,  format 
&  storage  to  know  if  it 
was  useable  to  us. 


It  could  be  helpful  if 
the  database  was  of 
the  resolution  and 
content  that  was 
needed  and  also  in  a 
format  that  allowed 
for 

translation/conversion 
into  desired  format. 


I  could  contact  the 
person  and  ask  more 
questions  about  the 
database  to  make 
sure  it  is  suited  to  my 
needs. 


We  currently  do  that 
for  all  constructive 
terrain  generated  in 
the  NSC,  although  we 
are  not  the  only  ones 
who  generate  terrain 
or  edit  terrain. 


Would  perfer  to  have 
a  direct  source  to 
determine  accuracy 
of  terrain  and  post 
directly  to  site.  There 
is  a  potential  to  have 
several  individuals  on 
the  registry  posting 
several  different 
versions  of  the  same 
terrain  database. 


Locating  the 
database  is  the  most 
difficult  part  of  the 


true  use/value.  That  certainly 
would  contribute  to  the 
ranking/answers  of  20  and 
below. 


That  would  be  better.  Then  we 
could  look  to  see  if  it  fit  our 
needs  before  downloading  it. 


It  would  accelerate  the  process 
of  getting  the  database, 
especially  for  mission 
rehearsal  scenarios. 


We  are  currently  trying  to  work 
this  issue  here,  but  due  to 
security  limitations,  have  been 
unable  to  come  up  with  an 
acceptable  system. 


This  is  slightly  better,  but  the 
problems  still  exist  determining 
accuracy  of  the  terrain 
database. 


Download  would  be  more 
useful  but  not  essential. 
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8  Yes  Yes 

19  No  No 


problem  since  there 
is  no  exhaustive 
central  registry  that 
exists  today.  Current 
searches  tend  to  be 
very  ad  hoc  and 

haphazard. _ 

Because  I  could  use 
that  to  contact  the 
person  and  determine 
whether  the  database 
was  suitable  "out  of 
the  box"  for  our 
needs,  whether  it  was 
pretty  close,  or 
whether  it  was  not 
useful 


N/A 


Because  I  could  use  that  to 
contact  the  person  and 
determine  whether  the 
database  was  suitable  "out  of 
the  box"  for  our  needs, 
whether  it  was  pretty  close,  or 
whether  it  was  not  useful  -  OR 
- 1  could  download  that 
database  and  determine 
potentially  easily  for  myself 


N/A 


How  important  are  these  attributes  of  a  registry?  (1-4,  4  is  most  important 


Level  of  detail 
required 


2 

3 

1 

2 

1 

3 

The  following  results  are  split  into  two  sections,  again  for  clarity. 


Rate  these  according  to  their  importance  as  metadata,  1-19,  1  is  most  important 


Geotypical 

or 

Geospecific 

Geo 

Extent 

5 

2 

2 

3 

11 

14 

9 

10 

(continuation  of  previous  responses) 


Rate  these  according  to  their  importance  as  metadata,  1-19,  1  is  most  important 


DB 

Generation 

Tools 


18 


Export 

Format 


8 


Platform 


15 


Technical 

POC 

Notes 

17 

19 

6 

16 

8 

12 

18 

16 

17 

8 

16 

19 

6 

18 

11 

10 

11 

19 

8 

16 

18 

12 

18 

19 

18 

15 

17 

9 

10 

11 

16 

17 

18 

16 

14 

1 

17 

5 

6 

Common  TDB  Variations 


Additional  Comments 


DTED  versus  HRTE  -  each  have  varying  degrees  of 
accuracy  Method  of  collection  -  SRT  versus  imagery, 
etc  Method  of  compilation  Classification  system  -  ie  soil 
example  stated  in  question 


What  was  the  source  and  resolution  of  the  linear  and 
areal  feature  data.  What  was  the  source  of  the  imagery 
used  and  what  was  the  resolution.  What  was  the 
source  of  the  elevation  data  and  what  was  the 
resolution.  Are  the  features  integrated  into  the  surface? 
ie:  Do  the  roads  lay  flat?  Is  the  surface  gridded  or 
tinned?  Is  the  data  releaseable  to  DoD  and  DoD 
contractors  only?  What  are  the  formats  of  the  data  for  a 
geographic  region?  What  is  the  size  of  each  data  set 
for  that  geographic  region?  Is  the  data  multicell  or 
single  cell?  Are  the  3d  models  geospecific,  geotypical 
or  both?  Are  the  3d  models  Multiple  Elevation 
Structures  (MES)  structures  or  not?  What  software 
would  you  typically  use  to  display  the  data? 


Good  luck  -  this  is  really  as  much  a  function  of  the 
runtime/federate  as  it  is  of  the  TDB  itself.  Elevation 
source  and  resulting  construct  Cultural  source,  content 
and  use  Geotypical  vice  geospecific  Soil/water/vegation 
Buildings  and  density  Airfields  and  representation  Ports 
and  representation  This  doesn’t  answer  your  question 
probably,  but  I'm  stopping  here.  You  could  almost 
choose  to  use  some  sort  of  adaptation  of  the  FACC  list 
and  just  check  off  what's  there  as  a  start  point. 


I've  got  two  web  sites  that  provide 
the  type  of  access  that  you  are 
considering  developing.  They  are 
sponsored  by  the  Defense  Modeling 
and  Simulation  Office  and  the  site  is 
called  the  Master  Environmental 
Library,  http://mel.dmso.mil 
http://mel.nrl-mry.navy.smil.mil 


TDBs  that  would  meet  BLCSE 
requirements  are  generally 
measured  today  in  10s  of  Gbs.  This 
is  not  an  FTP  type  transaction  for 
most  users.  Some  of  the  premise  of 
this  study  may  not  be  applicable  to 
power  users  or  users  that  require 
geographically  large,  yet 
complex/robust  TDBs/environments. 
You  will  always  have  to  consider 
how  these  are  handled  from  a 
source  data  (specifically  NGA)  and 
other  potential  licensing  issues  of  the 
end  product.  Neither  of  these  are 
well  understood  by  the  majority  of 
the  community,  nor  have  they  been 
historically  followed  to  any  degree  (at 
least  in  my  experience).  No  one  uses 
SI  000  anymore  (or  they  shouldn't  be 
or  God  Bless  them  if  they  are). 
Likewise,  I  think  your  survey  is 
SEDRIS  biased  as  that  remains  a 
non-factor,  at  least  for  us.  The  term 
export  format  is  a  little  confusing  as 
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Not  sure  of  the  question  being  asked.  Could  you 
clarify? 


What  data  model  is  used  to  represent  the  features  of 
the  terrain  database.  What  type  of  trianguiation  method 
is  used  -  gridded  vs  irregular  TINs.  Integrated  features 
or  applique  (overlayed)  features. 


MAJ  Martin  -  I'm  not  sure  how  I  got  identified  as  a  'key 
stakeholder'.  My  only  experience  with  databases  was 
as  a  player  or  user  during  my  military  career  (UCOFT, 
SIMNET,  CCTT,  JANUS,  BBS,  CBS).  In  my  work  on 
the  FCS  program  I've  been  involved  in  several 
discussions  regarding  data  and  data  bases.  I  don't  have 
a  preference  other  than  the  specific  needs  of  the 
warfighter  -  can  he  access,  manipulate  and  display  the 
data?  Does  the  data  have  the  required 
resolution/fidelity  in  terms  of  elevation  data  and  feature 
data?  Can  the  warfighter  update  the  data  base  with 
more  current  or  'better  data'  collected  by  the  warfighter 
(organic  sensors).  This  probably  isn't  much  help  but  its 
the  best  1  can  offer  for  now.  TJ  Smith 


Common  Variations.  -Format  of  the  data  (SEDRIS, 
OTF,  CTDB  etc).  -Regular  TIN  (CCTT)  vs  ITIN  (OTF).  - 
Are  roads  integrated  in  the  terrain  database?  -Polygon 
Attribution.  -Spatial  Reference  Frames  used  in  the 
different  databases.  -Given  a  SEDRIS  (STF)  database, 
is  the  terrain  skin  represented  as  a  regular  grid  or  as  an 
Integrated  Triangulated  Irregular  Network  (ITIN)? 


The  effects  due  to  terrain  are  most  important  to  us. 


Those  which  are  important  to  our  location  were 
included  in  question  21. 


Urban  area  fideli 


Slope  Vegetation  Buildings  Obtacles  Roads  Soil 
Streams/Rivers  Water 


Not  sure  I  see  a  question  here  but  I  believe  you  are 
asking  what  are  the  important  attributions.  This 
depends  of  the  level  of  detail  and  the  size  unit  we  are 
studying.  Assuming  I  understand  the  question  here  it 


well  -  do  you  really  mean  runtime 
format  (which  is  absent  from  the 
list)?  Platform  is  confusing  as  this  is 
really  more  related  to  run  time  format 
ctdb,  flight,  Janus,  etc 


A  helpful  addendum  for  the  registry 
would  be  the  available  data 
conversion  sofware  with  descriptions 
of  transformations  achievable  by 
using  each  and  which  simulations 
they  are  typically  paired  with.  Also, 
extent  and  types  of  metadata 
associated  with  each  data  set  would 
be  nice  as  well. 


I  think  that  the  most  important  part  of 
a  database  repository  would  be 
detailed  metadata  that  could  support 
complex  queries  which  are  always 
needed  to  find  a  database  suited  for 
a  particular  purpose. 


None 


NOTE  on  questoin  21  -  Only  about 
the  1  st  6-7  characteristice  are 
applicable  to  our  location,  so  from 
about  8  on,  they  are  just  ranked  in 
order  of  a  appearance,  not  need. 


It  would  be  very  difficult  for  us  to 
populate  this  database  with  terrain 
we  have  built.  Many  are  sensitive  in 
nature  or  are  proprietary. 


Talk  to  Paul  Dykes,  Fie  is  building 
the  global  soils  data  base  for  NGA. 
Paul  T.  Dyke  Blackland  Research 
Center  Texas  A&M  University 
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goes.  Standard  ITD  data  attributions  Soil  %sand  %silt 
%clay  %Moisture  Content  (at  time  database  was 
created)  %Hydraulic  Conductivity  of  the  Soil  at 
Saturation  %Tension  at  Saturation  %Macro  Pore 
Structure,  Torturosity  Elevation  Vegetation  Tree  Type 
Bush  Type  Grass  Type  Density  vs  stem  spacing 
Obstacles  Surface  Roughness  (for  radar  and  vehicle 
ride)  Temperature  Brightness  Emissivity  between  8  and 
14  microns  Rivers  Depth  Width  Streams  Depth  Width 

17 

Number  one  is  more  detail  on  source  data,  e.g.,: 
Elevation  data  source:  -  NGA  DTED  Level  1/2,  etc  - 
RTV  High  Resolution  Terrain  Elevation  (HRTE)  Level 
4/5,  etc.  -  USGS  DEM/Granularity  -  other  Feature  data 
source:  -  NGA  VMAP  Level  0  (1:1,000,000  scale)  Level 

1  (1 :250,000  scale)  Level  2  (1 :50,000  scale),  Urban 
Vector  Map  (1:12,500  scale),  etc.  -  NGA  DTOP/MSD 
Level  1-5  -  NGA  ITD/PITD/VITD,  etc.  -  RTV  shape  files 

-  other  sources/format  Imagery  data  source:  -  NGA  CIB 
1-30  (meter)  -  commercial  imagery/source/granularity  - 
other  sources/granulariy  Cartographic  Source  products 

-  NGA  CADRG/scale  -  other  sources/scale  For  export 
formats,  delineate  candidates:  -  NGA  VPF  -  ESRI 

Shape  Files  -  SEDRIS  Transmittal  Format  (STF)  - 
MultiGen  OpenFlight  -  etc. 

18 

- 1  believe  it  would  be  useful  to  have  the  capability  to 
determine  whether  certain  features  are  avialable  in  a 
terrain  database  (e.g.,  dams,  bridges,  tunnels);  It  would 
also  be  useful  to  know  what  the  source  data  is  for  these 
features  or  whether/how  the  data  was  inferred  - 1 
believe  it  would  also  be  useful  to  know  whether  the 
terrain  database  contained  buildings  and  whether  these 
buildings  had  interiors  (can  Dl  enter  the  building,  e.g.)  - 
As  far  as  classification  systems  for  features,  1  would 
say:  (a)  soil  type  (b)  bridge  load  classification  (c) 
building  material/construction  (what  a  building  is 
principally  constructed  from) 

19 
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System  720  East  Blackland  Road 
Temple,  Texas  76502  e-mail 
dyke@brc.tamus.edu  Phone:254- 
774-6059  (office)  Phone:254-774- 
6000  (secretary)  Fax:254-774-6001 
Talk  to  https://afweather.afwa.af.mil/ 
as  they  keep  a  ground  moisture  map 
of  the  world.  Talk  to  NGA  and  TEC. 
Niki  can  give  you  POC  at  these  sites, 
but  Nancy  Gardner  is  a  good 
individual  Talk  to  Fort  Knox  Major 
(RET)  Joe  Burns  who  is  creating  the 
database  for  SAF  at  Knox.  And  of 
course  there  is  JAUS  which  is  the 
DOD  organization  for  comunication 
between  Unmanned  Systems.  But 
they  have  not  worked  on  how  to 
communicate  terrain  between 
systems.  Hope  this  helps 


A  very  good  start.  An  admin  note,  in 
addition  to  submit/reset,  it  would  be 
a  good  idea  to  have  a  third  option  to 
"save"  the  project  if  someone  wishes 
to  continue  work  later.  At  one  time,  I 
felt  the  download  capability  would  be 
very  important,  but  with  database 
sizes  increasing,  it  should  be 
adequate  to  simply  give  the  option 
for  ftp  for  smaller  databases  or  for 


larger  ones,  FedEx/USMail 
depending  on  urgency. 


Appendix  E,  Questionnaire  2 


My  name  is  Major  Grant  Martin,  and  I  am  an  analyst  in  the  Operations  Research  Center 
in  the  Department  of  Systems  Engineering  at  the  United  States  Military  Academy.  I  am 
conducting  a  study  on  behalf  of  COL  Stone,  Director  of  the  Battle  Command,  Simulation  and 
Experimentation  Directorate  (BCSE),  formerly  AMSO.  The  purpose  of  the  study  is  to  identify 
the  metadata  needed  to  efficiently  organize  and  provide  access  to  modeling  and  simulation 
terrain  databases.  This  is  the  second  and  final  questionnaire  which  will  be  used  in  the  study. 

The  goal  of  this  questionnaire  is  to  gather  feedback  from  experts  in  the  field  as  to  which 
metadata  are  truly  important  and  would  be  beneficial  in  managing  these  databases.  You  received 
this  because  you  were  identified  as  an  important  individual  in  this  field.  Your  input  is  critical  to 
the  development  of  a  useful  product  for  the  modeling  and  simulation  community.  I  appreciate 
your  taking  the  time  to  provide  your  answers.  If  you  have  any  questions  or  would  like  more 
information  about  this  study,  please  feel  free  to  contact  me  at  phillip.martin@usma.cdu  or  (845) 
938-5661. 


1.  Name: 


2.  Organization: 


3.  Email  address: 


4.  Phone  number:  I 

5.  In  working  with  terrain  databases,  how  would  you  describe  your  primary  role?  (please 
choose  only  one) 


A,  Terrain  Database  Builder 


B.  Terrain  Database  User 

C.  Terrain  Database  Manager 

D.  Other  (please  specify  below) 

If  you  selected  D.  Other: 
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6.  In  working  with  terrain  databases,  do  you  have  a  secondary  role?  (please  choose  only  one) 


A.  Terrain  Database  Builder 


B.  Terrain  Database  User 

C.  Terrain  Database  Manager 

D.  Other  (please  specify  below) 

If  you  selected  D.  Other: 


7.  How  long  have  you  worked  with  terrain  databases? 


A.  0-1  Years 

B.  1-5  Years 

C.  5+ Years 


8.  On  a  scale  of  1-5,  how  would  you  describe  your  level  of  experience  in  working  with  terrain 
databases?  (1  denotes  little  experience,  5  denotes  much  experience) 


1 

2 

3 

4 

5 


9.  As  you  answer  the  following  questions  about  required  or  desired  fields  of  metadata,  please 
consider  that  this  metadata  framework  will  be  used  by  people  with  a  variety  of  needs: 

A  terrain  database  manager  who  will  use  this  framework  to  maintain  their  agency’s  terrain 
databases; 

An  analyst  who  would  use  a  terrain  database  as  part  of  a  simulation  study  who  will  use  the 
framework  to  search  for  a  particular  terrain  database; 

A  terrain  database  builder  who  will  repose  his  or  her  databases  here. 
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Please  also  consider  the  types  of  analysis  you  have  done  or  will  do  in  the  future.  Based  on  your 
experience,  which  of  the  following  would  be  “Required  entries,”  which  would  be  “Not  required,” 
and  which  would  be  “Not  required,  but  desired?” 

Please  simply  mark: 

R  for  a  required  item 

NR  for  a  not  required  item 

D  for  a  not  required  (but  desired)  item 

Please  mark  all  items.  Each  entry  can  only  have  one  mark. 


R 

NR 

D  Location 


R 

NR 

D  Format  (Janus  version,  OneSAF,  JCATS,  etc.) 


R 

NR 

D  Application  (System,  Open  Flight,  etc) 


R 

NR 

D  Topography  Representation  (Grid,  TIN,  other) 


R 

NR 

D  Terrain  database  coordinate  system  used 


R 

NR 

D  Elevation  source  data  with  resolution  (DTED  1,  2,  3,  HRTE  4,  5,  6  or  equivalent) 


R 

NR 

D  Cultural  source  data  with  resolution  (DTOP  1,  2,  3,  4,  5  or  equivalent) 
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IR 
NR 
D 


Originating  agency  (USATEC) 


R 

NR 

D  Lineage  (history  of  changes  you’ve  made  to  the  DB) 


R 

NR 

D  Publication  date 


R 

NR 

D 


Title 


R 

NR 

D  Are  road  networks  depicted?  Yes/No 


R 

NR 

D  Are  structures  depicted? 


R 

NR 

D  Is  vegetation  depicted? 


R 

NR 

D  Are  soil  types  depicted? 


No/2D/3D 


Yes/No 


Yes/No 


R 

NR 

D  Are  cultural  features  (churches,  hospitals,  etc)  depicted? 


R 

NR 

D  Is  hydrology  depicted?  Yes/No 


R 

NR 

D  Are  littoral  features  depicted?  Yes/No 


Yes/No 
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Are  utilities  depicted?  (sewers,  power  lines)  Yes/No 


R 

NR 

D 


R 

NR 

D  Are  atmospheric  effects  depicted?  Yes/No/NA 


R 

NR 

D  Is  dynamic  terrain  represented?  Yes  /  No 


R 

NR 

D  Is  it  SEDRIS-compliant?  Yes  /  No 


R 

NR 

D  System  (hardware  /  software)  requirements 


R 

NR 

D  Point  of  contact 


10.  Of  other  features  and  attributes  that  could  be  included  in  this  metadata,  are  there  some  that 
you  believe  should  be  included,  either  as  a  required  or  optional  entry? 


1 1 .  How  are  you  most  comfortable  describing  or  searching  for  a  location  of  a  terrain  database? 


A.  Geographic  Hace  Name  (e.g.  Fort  Hood) 

B.  Center  of  Mass  (a  single  latitude  /  longitude) 

C.  Boundaries  (low  er-left,  upper-right  latitude  /  longitude) 
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12.  Please  rate  the  following  statements  from  1  to  5,  1  meaning  you  strongly  disagree,  5 
meaning  you  strongly  agree,  3  means  you  neither  agree  nor  disagree. 


a.  It  would  be  useful  to  have  the  ability  for  users  to  “post”  opinions  or  useful  information  about 
a  particular  terrain  database  after  using  it. 


1 

2 

3 

4 

5 


b.  It  would  be  useful  to  have  an  email  reflector  so  that  you  could  post  a  question  about  the 
availability  of  a  database  to  a  wide  audience  in  the  community. 


1 

2 

3 

4 

5 


c.  It  would  be  useful  to  have  the  ability  to  provide  additional  metadata  about  a  terrain  database 
after  using  it. 


1 

2 

3 

4 

5 
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Appendix  F,  Organizations  Targeted  by  Questionnaire  2 

Stars  represent  organizations  who  provided  a  response  (some  had  more  than  one 
individual  respond) 

Boeing* 

Contractor  Test  Support  Facility  (CTSF) 

Department  of  Geography  and  Environmental  Engineering,  USMA* 

DTRA* 

FCS  LSI* 

Future  Combat  System  Lead  System  Integrator  and  Training  Integrated  Product  Team 
(FCS  LSI  and  Training  IPT)* 

MANSCEN* 

Natick  Soldier  Center* 

National  Geospatial  Intelligence  Agency  (NGA)* 

NGIT* 

NSC* 

PEO  STRI* 

PM  FCS* 

RDECOM 

SBL* 

TPIO- Virtual* 

TPIO-Terrain  Data* 

TPIO-Battle  Command* 

TRAC-Monterey 

TRAC-WSMR* 

TRADOC  Futures  Center* 

UAMBL 

US  Army  ERDC-TEC* 
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Appendix  G,  Explanation  of  Fields  in  Questionnaire  2 


Are  structures  represented 

Does  the  database  represent  man-made 

structures? 

Publication  date 

What  was  the  original  date  of  creation  of 

this  database? 

Are  cultural  features  represented 

Does  the  database  represent  features  such 

as  churches,  hospitals,  schools? 

Is  hydrology  represented 

Does  the  database  represent  hydrologic 

features,  such  as  rivers,  lakes,  as  well  as 

the  adjoining  land  (riverbanks)? 

Cultural  source  data 

What  is  the  level  of  detail  of  cultural 

source  data  (DTOP  level)? 

Are  soil  types  represented 

Does  the  database  represent  varied  soil 

types? 

Are  littoral  features  represented 

Does  the  database  represent  elements 

common  to  coastal  features? 

Lineage 

(If  needed)  what  is  the  history  of  changes 

to  this  database?  What  was  the  original 

database,  and  how  have  you  or  others 

you  know  of  altered  it? 

Title 

What  is  the  name  of  the  database? 

Are  atmospheric  effects  represented 

Does  the  database  represent  atmospheric 

effects  such  as  weather,  wind,  fog? 

SEDRIS-compliant 

Is  the  database  compatible  for  SEDRIS 

conversion? 

Coordinate  system 

Is  the  database  organized  by  latitude, 

longitude  or  the  Military  Grid  Reference 

System? 

Format 

What  software  platform  (OOS,  JCATS) 

does  this  database  support? 
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Location 

What  is  the  location  represented? 

Are  roads  represented 

Does  the  database  represent  roads? 

Is  vegetation  represented 

Does  the  database  represent  vegetation? 

Elevation  source  data 

What  is  the  base  elevation  source  data 

(DTED  levels)? 

Point  of  Contact 

Who  is  the  individual  responsible  for  the 

database?  Who  would  one  contact  to 

request  it? 

Topography  representation 

Is  the  database  organized  in  a  grid 

system,  or  are  the  elevation  postings  in 

Triangulated  Irregular  Networks  (TINs)? 

Application 

Is  the  database  in  a  run-time  format  or  a 

viewing  file?  Can  a  computer-generated 

force  interact  with  the  elements 

represented? 

Are  utilities  represented 

Does  the  database  represent  utilities  such 

as  power  or  telephone  lines  or  sewers? 

Is  dynamic  terrain  represented 

Does  the  database  represent  the  effects  of 

battlefield  action  (rubble,  craters)? 

Originating  agency 

What  is  the  original  source  of  the 

database? 

System  requirements 

What  hardware  or  software  requirements 

must  be  met  to  use  this  database? 

58 


Appendix  H,  Results  of  Questionnaire  2 

Again  we  have  identified  the  responses  by  a  number,  rather  than  individual’s  names.  It  is 
possible  (and  did  occur)  for  a  respondent  to  not  enter  some  information,  in  which  case  the  block 
is  empty.  These  results  are  organized  in  sections  to  make  the  reading  clearer. 


Background  information  about  the  respondents 


Primary 

Role 

Other  Primary 
Role 

Secondary 

Role 

Other 

Secondary  Role 

Time 

Working 

With 

TDBs 

Experience 
Level  (5  is 
high) 

1 

C.  Terrain 
Database 
Manager 

A.  Terrain 
Database 
Builder 

C.  5+ 

Years 

4 

2 

D.  Other 
(please 
specify 
below) 

DoD  M&S 

Terrain 

Executive  Agent 

D.  Other 
(please 
specify 
below) 

GEOINT 
Standards  for 
Terrain  Data 

C.  5+ 

Years 

5 

3 

C.  Terrain 
Database 
Manager 

A.  Terrain 
Database 
Builder 

C.  5+ 

Years 

5 

4 

B.  Terrain 
Database 
User 

A.  Terrain 
Database 
Builder 

C.  5+ 

Years 

2 

5 

A.  Terrain 
Database 
Builder 

D.  Other 
(please 
specify 
below) 

Terrain 

Database 

Integrator 

C.  5+ 
Years 

5 

6 

D.  Other 
(please 
specify 
below) 

1  build,  use,  and 
manage 

D.  Other 
(please 
specify 
below) 

My  roles  switch 
around 

C.  5+ 
Years 

3 

7 

A.  Terrain 
Database 
Builder 

B.  Terrain 
Database 
User 

C.  5+ 
Years 

4 

8 

B.  Terrain 
Database 
User 

C.  Terrain 
Database 
Manager 

C.  5+ 
Years 

4 

9 

D.  Other 
(please 
specify 
below) 

Terrain 

Database 
requirements  for 
C2  systems 

A.  Terrain 
Database 
Builder 

Terrain 

Database 

requirements 

forsimualtions 

C.  5+ 
Years 

2 

10 

C.  Terrain 
Database 
Manager 

All  of  the  above 
really 

A.  Terrain 
Database 
Builder 

1  am  also  a  user 

C.  5+ 
Years 

4 

11 

B.  Terrain 
Database 
User 

C.  Terrain 
Database 
Manager 

C.  5+ 
Years 

5 

12 

D.  Other 

(please 

specify 

other 

D.  Other 

(please 

specify 

other 

A.  0-1 
Years 

1 
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13 


A.  Terrain 
Database 
14  Builder 


below 


B.  Terrain 
Database 
User 


B.  Terrain 
Database 
User 


B.  Terrain 
Database 
User 


B.  Terrain 
Database 
User 


20 


B.  Terrain 
Database 
21  User 


B.  Terrain 
Database 
22  User 


Software 

Developer 


B.  Terrain 
Database 
User 


A.  Terrain 
Database 
Builder 


A.  Terrain 
Database 
Builder 


B.  Terrain 
Database 
User 


A.  Terrain 
Database 
Builder 


B.  Terrain 
Database 
User 


A.  Terrain 
Database 
Builder 


Requirements 

definer 


A.  Terrain 
Database 
Builder 


C.  Terrain 
Database 


Integration  of 
Terrain  Data 
into  the  LVC-IA 


Analyst  for 
system 

A.  Terrain 

capabilities  and 

Database 

requirements 

Builder 

B.  1-5 
Years 


C.  5+ 
Years 


C.  5+ 
Years 


B.  1-5 
Years 


C.  5+ 
Years 


C.  5+ 
Years 


C.  5+ 
Years 


C.  5+ 
Years 


C.  5+ 
Years 


C.  5+ 
Years 
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specify 

below) 

Manager 

Selection  of  fields  as  Required  (R),  Desired  (D),  or  Not  Required  (NR)  (organized 


in  several  sections) 


Resp.  ID 

Location 

Format 

(Janus, 

OOS) 

Application 

Topography 

Rep. 

Coordinate 

System 

Used 

Elevation 
Source  Data 
w/Resolution 

Cultural 
Source  Data 
w/Resolution 

1 

D 

R 

R 

R 

R 

D 

D 

2 

R 

R 

D 

R 

R 

R 

R 

3 

R 

R 

R 

R 

R 

R 

R 

4 

R 

R 

R 

R 

R 

R 

R 

5 

R 

R 

R 

R 

R 

R 

R 

6 

R 

R 

D 

D 

R 

D 

D 

7 

R 

R 

D 

R 

R 

R 

R 

8 

R 

R 

R 

R 

R 

R 

R 

9 

R 

D 

D 

R 

R 

R 

D 

10 

R 

R 

NR 

R 

R 

R 

R 

11 

R 

R 

R 

R 

R 

R 

R 

12 

R 

R 

R 

R 

R 

13 

R 

R 

R 

D 

R 

R 

R 

14 

D 

R 

D 

D 

R 

R 

R 

15 

R 

R 

R 

R 

R 

R 

R 

16 

R 

R 

R 

R 

R 

R 

D 

17 

R 

R 

R 

D 

R 

D 

D 

18 

R 

R 

R 

R 

R 

R 

R 

19 

R 

R 

R 

R 

R 

R 

R 

20 

R 

R 

R 

R 

R 

R 

R 

21 

R 

R 

R 

R 

R 

R 

D 

22 

R 

R 

R 

R 

R 

R 

NR 

23 

R 

R 

D 

R 

R 

D 

D 

24 

R 

R 

R 

R 

R 

R 

R 

25 

R 

R 

NR 

NR 

R 

R 

R 

26 

R 

R 

R 

R 

R 

R 

R 

27 

R 

R 

R 

R 

R 

D 

D 

28 

R 

R 

D 

D 

D 

R 

R 
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13  D 


14  NR 


15  R 


16  R 


17  R 


18  NR 


19  R 


20  R 


21  D 


22  NR 


23  D 


24 


25 


26  I  D 


27  D 


28  D 


Pub. 

Date 

Title 

Roads 

Structures 

D 

D 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

D 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

D 

R 

R 

D 

D 

R 

D 

R 

R 

D 

D 

R 

R 

R 

R 

R 

R 

R 

R 

D 

D 

R 

R 

R 

R 

R 

R 

R 

R 

R 

NR 

R 

R 

R 

R 

R 

NR 

D 

D 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

NR 

D 

D 

D 

D 

NR 

R 

R 

R 

R 

NR 

NR 

R 

R 

R 

R 

D 

D 

R 

R 

D 

D 

R 

R 

R 

D 

R 

R 

Cultural 

features 


9  D 


10  D 


11  R 


12  D 


13  R 


14  R 


15  NR 


16  R 


17  D 


18  R 


Hydrolo 


R 


R 


R 


R 


R 


R 


R 


R 


R 


D 


R 


R 


D 


R 


NR 


R 


D 


R 


Littoral 

Utilities 

Atmospheric 

Effects 

Dynamic 

Terrain 

D 

D 

D 

D 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

R 

D 

NR 

D 

D 

D 

D 

D 

R 

R 

R 

R 

R 

R 

R 

R 

R 

D 

R 

D 

R 

R 

D 

D 

NR 

NR 

NR 

R 

R 

R 

D 

D 

D 

D 

D 

D 

R 

R 

R 

R 
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19 


20 


21  D 


D 


R 


24  NR 


25  D 


26  R 


R 


R 
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Other  Features 


Intended  use  being  met  by  the  database  developer,  goes  beyond  a  system  name  and  should 
not  list  Openflight  or  other  interchange  format  in  this  area  (should  be  as  specific  as  possible 
but  even  broad  statements  like,  training,  analysis,  acquisition,  OT&E,  mission  rehearsal, 
planning,  and  operations  can  be  useful).  Full  specification  of  location  to  include  reference 
datum  as  well  as  coordinate  system.  Feature  data  dictionary  that  was  used  (FACC,  FADD, 
DFDD,  NFDD,  EDCS,  IHO  S-57,  or  ASCII  Text).  Databse  size  (data  volume)  and  organization 
(themes)  and  if  tiled.  Databse  Preview  capability  available  (what  software  and  where  to  look). 
Data  rights  issues  /  databse  owner  /  sponsor,  which  could  be  different  from  POC.  Need 
category  to  describe  the  surface  representation  (TIN,  TRN,  Splines  etc.)  as  well  as  source 
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DEM  (describe),  DTED  1,2,  HRTe  3-7  or?  Feature  data  format  (shapefiles  2d  or  3D,  VPF, 

SLF,  Openflight,  country  database,  or?)  Any  value  adding  to  source  data  should  be  captured 
as  well  as  classification  or  restricted  distribution  issues  this  ideally  would  provide  information 
down  to  the  attribute  /  attribute  value  -  enumeration  level.  All  sources  need  identified  to  include 
elevation,  features,  all  names  used  (with  location  for  fuzzy  features  like  mountain  ranges, 
deserts,  river  systems  etc.),  Is  the  database  available  in  a  pre-runtime  format  as  well  as 
runtime?  Information  on  any  associated  3D  Model  and  textures  libraries  that  were  used.  What 
weather  data  is  to  be  used  as  input  for  weather  effects  modeling?  Littoral  effects  models  and 
associated  source  data  for  long  shore  current,  rip  tides  etc.  What  tools  (like  DTSim)  are  used 
for  dynamic  effects  in  all  domains  (terrain,  ocean,  atmosphere)?  If  the  database  was  designed 
to  interface  with  a  simulation  federation,  what  environmental  server  was  it  providing 
information  to  or  receiving  information  from? 


All  features  and  attributes  required  for  compliance  with  applicable  Federal  Geographic  Data 
Committee  (FGDC)  and  International  Organization  for  Standardization  (ISO)  standards  for 
metadata. 


As  an  optional  entry,  it  would  be  good  to  have  information  further  detailing  features  (such  as 
soils  or  vegetation)  by  classification  systems  used.  In  other  words,  are  soils 
enumerated/designated  as  USCS  categories,  is  vegetation  an  areal  feature  using  ITD 
vegetation  themes,  etc.  Another  useful  but  not  required  entry  would  be  metadata  on  why  the 
terrain  database  was  created  -  for  a  particular  study,  for  an  experiment  such  as  DARPA  MC2, 
and  the  purpose.  This  could  help  orient  the  potential  user  about  the  focus  for  geotypical  or 
geospecific  date  and  areas  of  emphasis  (forests,  urban, ..)  Metadata  on  resolution  of  features 
(such  as  soils  based  on  FAO  1 :1  M  ...)  would  also  be  useful  (but  not  required) 


Projection  used  in  developing  database  Datum  used  in  developing  database  Source  material 
used  in  compilation  date  of  source  material  Date  of  comDilation 


Comment  on  questionare:  The  examples  for  Format  and  Application  are  misleading  and 
generally  reversed.  I  would  argue  that  Open  Flight  is  a  format  used  my  many  applications 
(although  orginally  created  by  Multi-Gen  for  their  visual  application)  and  that  OneSAF,  JCATS 
are  applications  (which  sometimes  have  proprietary  formats  which  mav  be  the  format  as  well. 


All  data  needs  to  be  injested  from  standard  NGA  formats  and  regenrerated  from  the  M&S 
box3s  without  additional  error 


The  datum  used  is  required.  The  item  that  says  "Terrain  database  coordinate  system  used"  is 
vague  about  this  point. 


Validity  level  for  individual  pieces  of  data  or  if  not  possible,  for  the  entire  set  (has  data  been 
generated  to  fill  a  gap,  surrogated,  supplied  by  humint,  derived  using  multiple  sources,  etc.) 
Images  or  digital  photos  of  cultural  features.  Availability  in  multiple  formats.  Stability  of 
individual  pieces  of  data. 


A  need  exists  to  list  Terrain  DB  supporting  tools  and  any  license  fees  associated  with 
supporting  tools  necessary  to  support  Terrain  database  use.  For  example,  OneSAF  may  have 
the  capability  to  impart  feature  data  into  the  proposed  OTF  format  using  the  EDM  and  other 
components  of  SEDRIS  but  it  does  not  help  if  they  are  not  populated.  One  would  have  to 
purchase  COTS  tools,  become  proficient  with  the  tool,  obtain  required  data  (if  not  available) 
and  then  populate  the  feature  data  as  needed  -  hopinq  it  would  work  as  advertised. 
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23 

Atmospheric  effects  are  usually  considered  a  separate  simulation  component  or  physical 
model.  Similarly,  dynamic  terrain  effects  are  usually  implemented  in  the  simulation  terrain 
runtime  component,  not  in  the  terrain  database  file:  Other  metadata  to  consider  include: 

Location  format  (lat/long,  UTM,  UPS,  geocentric,  tile  relative),  Longitude  zone  (even  if  UTM  is 
not  used),  Map  Datum,  is  terrain  paged  or  tiled?,  size  of  the  page  or  tile  (meters,  lat/long 
extents,  size  in  bytes),  number  of  polygons,  number  of  linear  vector  features,  number  of  vector 
feature  vertices,  average  and  maximum  polygon  density  (polygons  per  sq  Km). 

24 

The  only  reason  1  marked  NR  on  many  of  the  items  is  that  1  think  they  should  not  be  stated  as 
Y/N  but  briefly  described  by  source  and  process. 

25 

26 

27 

28 

The  Training  IPT  has  developed  a  list  of  over  800  features  and  900  attributes  that  are  required 
for  Training  in  FCS.  This  does  not  include  the  urban  area.  Those  features  and  attributes  will  be 
added  to  the  list  mentioned  above  between  now  and  mid  summer.  That  requirements  list  with 
its  pedigree  (mapped  to  Unit  of  Action  Missions,  then  to  the  Military  Functions  is  available  to 
you.  Also,  pedigree  to  FCS  ORD  and  SoS  Specification  is  available. 

(Basics  of  DTED)  http://www.fas.org/irp/program/core/dted.htm 
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